Need Design Ideas
-
I am developing an application that will allow the customer to purchase different snap-in components. These components represent versions of different technologies. As an example, if they own MS Word 2000, they can purchase the plugin MSWD2000.dll. If they own MS Word 2003, they can purchase the plugin MSWD2003.dll, and for MS Word 2007, they can purchase the plugin MSWD2007.dll, and so on. What I'm considering doing is creating an MSWord_Base class, then a MSWord_2000 class based off of it, then a MSWord_2003 class based off of the MSWord_2000 class, and so on. Each project would be in the same MSWord solution. This design allows me to generate seperate DLL's for each version of Word. 1) Anyone see any issues with this? I welcome better ideas 2) How would the app know what snap-ins are available? 3) How do I keep someone from using the DLL in another .Net app? I would want to prevent method calls from working unless the user is registered. Thanks
Everything makes sense in someone's mind
-
I am developing an application that will allow the customer to purchase different snap-in components. These components represent versions of different technologies. As an example, if they own MS Word 2000, they can purchase the plugin MSWD2000.dll. If they own MS Word 2003, they can purchase the plugin MSWD2003.dll, and for MS Word 2007, they can purchase the plugin MSWD2007.dll, and so on. What I'm considering doing is creating an MSWord_Base class, then a MSWord_2000 class based off of it, then a MSWord_2003 class based off of the MSWord_2000 class, and so on. Each project would be in the same MSWord solution. This design allows me to generate seperate DLL's for each version of Word. 1) Anyone see any issues with this? I welcome better ideas 2) How would the app know what snap-ins are available? 3) How do I keep someone from using the DLL in another .Net app? I would want to prevent method calls from working unless the user is registered. Thanks
Everything makes sense in someone's mind
Kevin Marois wrote:
- Anyone see any issues with this? I welcome better ideas
None worth mentioning.
Kevin Marois wrote:
- How would the app know what snap-ins are available?
Create a plugins directory in the same way that an application such as photoshop has. Let your application look for Dlls in this directory that match your plugin rules, and load them as appropriate. I would suggest that you would want to look into the Managed Extensibility Framework (MEF) from Microsoft to do this - it has the ability to automatically load items from a directory using something called a DirectoryCatalog.
Kevin Marois wrote:
- How do I keep someone from using the DLL in another .Net app?
I'd use a public/private key between your application and these DLLs (if I were you, I'd look to write it in an unmanaged language such as C++, and p/invoke it from both sides).
I'm not a stalker, I just know things. Oh by the way, you're out of milk.
Forgive your enemies - it messes with their heads
-
I am developing an application that will allow the customer to purchase different snap-in components. These components represent versions of different technologies. As an example, if they own MS Word 2000, they can purchase the plugin MSWD2000.dll. If they own MS Word 2003, they can purchase the plugin MSWD2003.dll, and for MS Word 2007, they can purchase the plugin MSWD2007.dll, and so on. What I'm considering doing is creating an MSWord_Base class, then a MSWord_2000 class based off of it, then a MSWord_2003 class based off of the MSWord_2000 class, and so on. Each project would be in the same MSWord solution. This design allows me to generate seperate DLL's for each version of Word. 1) Anyone see any issues with this? I welcome better ideas 2) How would the app know what snap-ins are available? 3) How do I keep someone from using the DLL in another .Net app? I would want to prevent method calls from working unless the user is registered. Thanks
Everything makes sense in someone's mind
Seems a fair way to go about it, but as a pondering point, might i propose an alternative: Strategy pattern have a single concrete MSWord class that calls out to strategies for each 'area' of logic (e.g. Import strategy, export strategy, gui embedding strategy, etc) Then provide strategy classes for each variation of each logic area Wrap the whole thing up in a factory pattern which decides which strategies to stick into the MSWord class when it is created. The advantage of this is that its more flexible should microsoft ever decide to revert functionality (so that, say version 3 has the same functionality as version 1 in some logical area but different from version 2) hope that makes sense