I spent my day reading articles/blogs about how to best share data between processes. I haven't had the opportunity to dive deep into this topic before, but I was wondering what the best solution would be in your opinion to handle the following.
I am developing an application that binds plugins using MEF. Plugins (mostly forms that are displayed as MDI forms) can have multiple interface implementations based on what they need/offer, the mainframe checks if they are implemented and then satisfies their needs. So far everything is fine, up and running.
Now if you start the app it asks for a valid login (MainFrame) and if the login succeeds the user is stored in the MainFrame. The PluginManager which knows about all the available plugins now passes the user into the plugin upon activation.
That works, but is it a good approach?
I also thought about having a AppEnvironment class that shares several information like User, DataConn-Strings etc. using static variables. The App uses Tasks a lot so I secured the static variables that may be changed during runtime using static locking objects.
I already read here about that static variables are bad... Is this really the case?
Another thing that I figured out is that I could use pipes to share information between the MainFrame and its child-forms... Isn't this a little bit overdosed? Do you like/use pipes for such requirements?
Don't get me wrong please, I am not searching for an easy way to archive what I want, but I really like to have a fine, elegant way to share the information within MainFrame and its ChildForms. If I can learn something new, even better ;)
Thanks for your attention, any help is kindly appreciated :)
Cheers Keil
Question: That works, but is it a good approach?
Answer: For simple scenarios it should possibly suffice.
One thing to remember about data sharing in case of extensible implementation is to "take care and prevent unknown or unwanted changes to your mainframe context data from plugin contexts"
Question: I already read here about that static variables are bad... Is this really the case?
Answer: No they are not bad in my opinion, delicate and should be handled with care when dealing with multi-threaded application.
Locking the variable will help to some extent and in few cases, I would recommend you looking into Interlocked class for more precautionary measures.
Question: Another thing that I figured out is that I could use pipes to share information between the MainFrame and its child-forms... Isn't this a little bit overdosed? Do you like/use pipes for such requirements?
Answer: Pipes are one of the fastest way to communicate between processes.
Case study: Used pipe based WCF service to get data between two windows service that deals with huge data request per second. This was the most feasible options for two service to talk on same machine using WCF.
I would go with your opinion and say it would be a bit of overkill to use pipe. Plus all the plugin that wants to be loaded in your app will technically have to implement this and will add more avoidable code for those plugin to maintain.
Summarize: The best living example pattern you can follow is the Visual Studio SDK. I would suggest to use some kind of commonly agreed commanding or messaging pattern. Both the parties need to know the message / command entities and a reference to the command handler or messenger which entertains those commands / messages. A controlled channel for interaction between your mainframe and the plugin code would be a way to go forward and still extensible.