Multiple COM Objects
-
I am creating an automation client similar to Microsoft Office applications. Now, to expose the functionality of the application to the plugin, I have created a component "IAs" which is kind of a group for "IA". Now the thing is there may be as many as 2000 "IA" created at a single time and they are dynamic which means I may have to destroy all the 2000 "IA" and recreate them again multiple times. Is using the method outlined above feasible? What kind of load would the PC have to bear? Would I be better of exposing just one interface and using that interface to manage the other sub components? Or would creating 2000 "IA" again and again be a better choice? Please help.
--- :beer: Hakuna-Matada :beer: It means no worries for the rest of your days... It's our problem free, Philosophy :jig: "I think my response was 'What idiot dreamed this up?'" -- Mary Ann Davidson, Oracle's chief security officer, in typical blunt manner, remembering her reaction to the company's scheme to brand its databases as "unbreakable."
-
I am creating an automation client similar to Microsoft Office applications. Now, to expose the functionality of the application to the plugin, I have created a component "IAs" which is kind of a group for "IA". Now the thing is there may be as many as 2000 "IA" created at a single time and they are dynamic which means I may have to destroy all the 2000 "IA" and recreate them again multiple times. Is using the method outlined above feasible? What kind of load would the PC have to bear? Would I be better of exposing just one interface and using that interface to manage the other sub components? Or would creating 2000 "IA" again and again be a better choice? Please help.
--- :beer: Hakuna-Matada :beer: It means no worries for the rest of your days... It's our problem free, Philosophy :jig: "I think my response was 'What idiot dreamed this up?'" -- Mary Ann Davidson, Oracle's chief security officer, in typical blunt manner, remembering her reaction to the company's scheme to brand its databases as "unbreakable."
Is "IA" similar to an application or component IA's "State"? I believe you need to think about a better design by considering the fact that these IA instances are not like normal C++ objects. There is an amount of Marshalling, Cross Apartment access, and out of process calls required which may affect performance. The design choice should also consider these aspects and not just the frequent memory allocation for example. So identify what exactly is the purpose of IA implemented instances and do you really need to expose them to client. Also how often will a "recreate" request come to you. Also the design choice you are talking about is 1. Expose all interface directly 2. Use a Facade to expose the functionality instead (See facade design pattern) Both work but only based on the exact need of problem you can find the best choice or a completely new way then what is said above. What you have mentioned is abstract, if you can provide more details then we can help better. These are my views so far. I hope they make sense in context of your problem
S o h a i l K a d i w a l a
To Err Is Human; to Debug, Divine -
Is "IA" similar to an application or component IA's "State"? I believe you need to think about a better design by considering the fact that these IA instances are not like normal C++ objects. There is an amount of Marshalling, Cross Apartment access, and out of process calls required which may affect performance. The design choice should also consider these aspects and not just the frequent memory allocation for example. So identify what exactly is the purpose of IA implemented instances and do you really need to expose them to client. Also how often will a "recreate" request come to you. Also the design choice you are talking about is 1. Expose all interface directly 2. Use a Facade to expose the functionality instead (See facade design pattern) Both work but only based on the exact need of problem you can find the best choice or a completely new way then what is said above. What you have mentioned is abstract, if you can provide more details then we can help better. These are my views so far. I hope they make sense in context of your problem
S o h a i l K a d i w a l a
To Err Is Human; to Debug, DivineThanks for your reply. I don't think I will be needing the Facade pattern. Let me rephrase my query. I have Categories and Elements which must be exposed by my Application. Elements belong to Categories and there are about 50 categories each containing around 50 to 100 elements. Categories have their own set of properties and Elements have their own set of properties and they have to refreshed periodically. Maybe at a frequency of once a minute or two. Now I was think of Implementing all the Categories and Elements and COM objects similar to what Microsoft does with its CommandBars and CommandBar Objects of the Office API. I have two designs in mind, ICategories->ICategory->IElements->IElement or just expose IElements have IElements expose functions via which every element can be reached and its corresponding category. Any suggestions? Which route should I take or is there a better way? :confused: Thanks once again for taking the time out to reply. :)
--- :beer: Hakuna-Matada :beer: It means no worries for the rest of your days... It's our problem free, Philosophy :jig: "I think my response was 'What idiot dreamed this up?'" -- Mary Ann Davidson, Oracle's chief security officer, in typical blunt manner, remembering her reaction to the company's scheme to brand its databases as "unbreakable."
-
Thanks for your reply. I don't think I will be needing the Facade pattern. Let me rephrase my query. I have Categories and Elements which must be exposed by my Application. Elements belong to Categories and there are about 50 categories each containing around 50 to 100 elements. Categories have their own set of properties and Elements have their own set of properties and they have to refreshed periodically. Maybe at a frequency of once a minute or two. Now I was think of Implementing all the Categories and Elements and COM objects similar to what Microsoft does with its CommandBars and CommandBar Objects of the Office API. I have two designs in mind, ICategories->ICategory->IElements->IElement or just expose IElements have IElements expose functions via which every element can be reached and its corresponding category. Any suggestions? Which route should I take or is there a better way? :confused: Thanks once again for taking the time out to reply. :)
--- :beer: Hakuna-Matada :beer: It means no worries for the rest of your days... It's our problem free, Philosophy :jig: "I think my response was 'What idiot dreamed this up?'" -- Mary Ann Davidson, Oracle's chief security officer, in typical blunt manner, remembering her reaction to the company's scheme to brand its databases as "unbreakable."
HakunaMatada wrote:
CommandBars and CommandBar Objects of the Office API
I would go by this. Also you have now mentioned that the individual Element needs to be refreshed, which contrasts recreated. Quick thoughts - - You may have ICategory - ICatgeory having a method which returns IElement collection - Support enumeration of element collection - foreach in VB if required - ICategory will have its own get/set properties to read and change its state or attribute - IElement will have its own get/set properties to read and change its state or attribute
S o h a i l K a d i w a l a
To Err Is Human; to Debug, Divine