Singleton vs Whatever Else Quandary
-
I'm stuck in this quandary on whether or not to redesign the underlying classes for an application that is almost ready to go live (currently in user testing). This is by-the-way where I spend a great deal of my time, in a quandary that is. I've already searched for alternatives, Google, CP, Stack Overflow, etc., with minimal hits where actual discussion had occurred. But first, some important background information. Where I work virtually all of our Windows applications are for internal use. To help with this we wrote a "menu" application that is used to load all of the other application, which in turn are compiled as dlls. This has worked fairly well, except the dlls are never unloaded from memory when the user closes the secondary application. These dlls are loaded in a fairly straightforward manner.
Assembly myDLL = Assembly.LoadFrom(baseURL + dbDllName);
With an eventual myForm.Show() to display the secondary application's starting form. I have several forms in my application and I've used a singleton design, http://csharpindepth.com/Articles/General/Singleton.aspx#lazy[^], for the main class that handles database calls, etc. This is so I don't have to pass an instance of the class around to multiple forms. The downside to using the singleton with an application loaded by our menu application is there is no limitation on how many instances of my application the user can load. This of course can lead to strange behavior to say the least. For example, performing a search in the first application instance updates the grids in all instances. Now, finally to my question. What are my options other than the two already mentioned, leave it as is and tell the user to not load more than one instance (seems highly unprofessional), remove the singleton and pass an instance of the first instance of the class to the other four forms (not my favorite thing to do). I'm not up on all the latest design patterns so any pointers would be helpful.
-
I'm stuck in this quandary on whether or not to redesign the underlying classes for an application that is almost ready to go live (currently in user testing). This is by-the-way where I spend a great deal of my time, in a quandary that is. I've already searched for alternatives, Google, CP, Stack Overflow, etc., with minimal hits where actual discussion had occurred. But first, some important background information. Where I work virtually all of our Windows applications are for internal use. To help with this we wrote a "menu" application that is used to load all of the other application, which in turn are compiled as dlls. This has worked fairly well, except the dlls are never unloaded from memory when the user closes the secondary application. These dlls are loaded in a fairly straightforward manner.
Assembly myDLL = Assembly.LoadFrom(baseURL + dbDllName);
With an eventual myForm.Show() to display the secondary application's starting form. I have several forms in my application and I've used a singleton design, http://csharpindepth.com/Articles/General/Singleton.aspx#lazy[^], for the main class that handles database calls, etc. This is so I don't have to pass an instance of the class around to multiple forms. The downside to using the singleton with an application loaded by our menu application is there is no limitation on how many instances of my application the user can load. This of course can lead to strange behavior to say the least. For example, performing a search in the first application instance updates the grids in all instances. Now, finally to my question. What are my options other than the two already mentioned, leave it as is and tell the user to not load more than one instance (seems highly unprofessional), remove the singleton and pass an instance of the first instance of the class to the other four forms (not my favorite thing to do). I'm not up on all the latest design patterns so any pointers would be helpful.
Seems to me that if your shell application is a singleton and cleans up when the children are closed then there should be no orphans.
Never underestimate the power of human stupidity RAH
-
I'm stuck in this quandary on whether or not to redesign the underlying classes for an application that is almost ready to go live (currently in user testing). This is by-the-way where I spend a great deal of my time, in a quandary that is. I've already searched for alternatives, Google, CP, Stack Overflow, etc., with minimal hits where actual discussion had occurred. But first, some important background information. Where I work virtually all of our Windows applications are for internal use. To help with this we wrote a "menu" application that is used to load all of the other application, which in turn are compiled as dlls. This has worked fairly well, except the dlls are never unloaded from memory when the user closes the secondary application. These dlls are loaded in a fairly straightforward manner.
Assembly myDLL = Assembly.LoadFrom(baseURL + dbDllName);
With an eventual myForm.Show() to display the secondary application's starting form. I have several forms in my application and I've used a singleton design, http://csharpindepth.com/Articles/General/Singleton.aspx#lazy[^], for the main class that handles database calls, etc. This is so I don't have to pass an instance of the class around to multiple forms. The downside to using the singleton with an application loaded by our menu application is there is no limitation on how many instances of my application the user can load. This of course can lead to strange behavior to say the least. For example, performing a search in the first application instance updates the grids in all instances. Now, finally to my question. What are my options other than the two already mentioned, leave it as is and tell the user to not load more than one instance (seems highly unprofessional), remove the singleton and pass an instance of the first instance of the class to the other four forms (not my favorite thing to do). I'm not up on all the latest design patterns so any pointers would be helpful.
To be honest, it sounds to me like you need to investigate hosting each separate application in its own AppDomain. Just tear down the domain when the app needs to be unloaded. This Will also give you the ability to remove issues surrounding strange behaviour due to sharing the same assemblies.
-
To be honest, it sounds to me like you need to investigate hosting each separate application in its own AppDomain. Just tear down the domain when the app needs to be unloaded. This Will also give you the ability to remove issues surrounding strange behaviour due to sharing the same assemblies.
I'm assuming you are referring to changing how the menu application loads the secondary apps. Unfortunately, I do not have any control over that code. And the last time I made a suggestion to change how the menu works, I got the distinct impression they felt I was attempting to pee in the office coffee pot.
-
I'm stuck in this quandary on whether or not to redesign the underlying classes for an application that is almost ready to go live (currently in user testing). This is by-the-way where I spend a great deal of my time, in a quandary that is. I've already searched for alternatives, Google, CP, Stack Overflow, etc., with minimal hits where actual discussion had occurred. But first, some important background information. Where I work virtually all of our Windows applications are for internal use. To help with this we wrote a "menu" application that is used to load all of the other application, which in turn are compiled as dlls. This has worked fairly well, except the dlls are never unloaded from memory when the user closes the secondary application. These dlls are loaded in a fairly straightforward manner.
Assembly myDLL = Assembly.LoadFrom(baseURL + dbDllName);
With an eventual myForm.Show() to display the secondary application's starting form. I have several forms in my application and I've used a singleton design, http://csharpindepth.com/Articles/General/Singleton.aspx#lazy[^], for the main class that handles database calls, etc. This is so I don't have to pass an instance of the class around to multiple forms. The downside to using the singleton with an application loaded by our menu application is there is no limitation on how many instances of my application the user can load. This of course can lead to strange behavior to say the least. For example, performing a search in the first application instance updates the grids in all instances. Now, finally to my question. What are my options other than the two already mentioned, leave it as is and tell the user to not load more than one instance (seems highly unprofessional), remove the singleton and pass an instance of the first instance of the class to the other four forms (not my favorite thing to do). I'm not up on all the latest design patterns so any pointers would be helpful.
SteveJD wrote:
This has worked fairly well, except the dlls are never unloaded from memory...For example, performing a search in the first application instance updates the grids in all instances.
This is a design problem and not a dll problem. Normally the only primary reason to unload a dll is because you need to load a new version of the dll without restarting the application. Yours is problem in the design - probably because you are using singletons. Simple solution is don't use singletons. Each user has their own set of instances of the classes. There is no data overlap.
SteveJD wrote:
I'm not up on all the latest design patterns
General consensus is that one shouldn't use Singletons...ever. I wouldn't go that far as sometimes the appearance of a singleton can be an effective way to manage access to some resource. But there should be very few of them in the application and of course they would need to be usable by many threads at the same time (thus there could not be a problem as you are having.)