I stand in front of a little problem; I want to create a modular software.
Let's make it more general and not specific for my case. What I want to create is a software which loads dlls and those dlls adds features to the software.
Think of the dlls as xvid, divx or whatever additional codec, feature to your favorite video-player. I want a more custom modular program though, in my case I'm creating a software to handle Customers, Invoices and Products and different users might have different needs and therefore I need to handle this somehow!
However, re-compiling the software and specificly sending the new files to each different user is "stupid" I would rather create a modular software ( don't actually know if this is the correct term ).
So what I was thinking is that I begin creating a pattern of which my DLL's should follow.
Then I create a Module handler in my software which loads the actuall DLL and calls the method in it ( here's where the pattern come in! ).
What I'd like to know is; Am I on the right track?
Might you guys give me some pointers or examples on this matter?
This is all in C#, but would of course be interesting to see how it would differ in Java, Python or C++ too.
create a common interface IMyInterface for your classes which should include everything that is common between all of your Moduals. You should look into the Managed Extensibility Framework I believe you can get it from Codeplex.
You have to have a purpose. You either need the module to conform to some kind of interface or something the app can handle (like a method with a known attribute that you find via reflection). The interface then performs known functionality like invoice creation, invoice printing, etc.
Alternatively your app has to conform to some interface and uses hooks for the module to use to inject itself into your app.
Plugins would be good for something that can be easily sliced up (media codecs). Hooks would be good for something with a well-defined event model (like a web server). Which you use depends on how you want your modularity for customers, invoices, etc. to work.
Here is a similar SO thread. Here's a list of dependency injection frameworks, Microsoft's is Unity. Also, you can look at the Enterprise Library codebase to see how they implement their provider architecture, such as in the caching application block where you can plug in your own caching provider.
Related
I'm looking for input on a direction to take for building an accounting application. The application needs to allow for high customization, sometimes entire processes will need to changed.
I want a way to make changes without re-compiling the entire application when a customer has a specific modification request. The back-end will be a SQL database of some sort. Most likely SQL Server Express for cost reasons. The front-end will be C#.
I'm thinking of an event-based system that will have events for when different types of actions, such as entries, are made. I would then have a plugin system that handles the event. I may need to have multiple processes apply in a specific order to the data before it is finally saved. It will need to trigger other processes as well.
I want to keep my base application the same, which works for most customers, but have a graceful way of loading the custom processes that other specific customers have.
I'm open to all suggestions. Even if they are thinking of completely different ways of approaching the problem. Our current in-house development talent is .NET and MS SQL Server. I'm not aware of a software pattern that may fit this situation.
Additional Info:
This isn't a completely blank slate system, it will have functionality that works for a large number of the customers. For various reasons, requirements change based on states and even at the region and town level where customization may be necessary.
I'd like to be able to plugin additional pre-compiled modules. When I started looking into possible options, I was imagining an empty handler that I could insert code into through a plugin. So say for example, a new entry is made to the general ledger that raises an event. The handler is called, but the handler's code is coming from a plugin, which may be my original process that fits 80% of the customers. If a customer wants a custom operation, I could add a plugin that completely replaces the original one or have it add an additional post processing step through another plugin after the original runs. Sort of a layering process I guess.
You could look at Managed Extensibility Framework
It provide rich composition layer features that allow you to build loosely-coupled plugin applications.
Update : sound like you need the pre-defined modules on different geographic areas and using chain of responsibility design patern might help you manage the principle of change.
Sorry no codes provided just throwing my thoughts
Windows Workflow Foundation (WF) (part of the .NET Framework) is a potential candidate for your requirements. It enables various actions, command-lets and script-lets to be composed dynamically so that you can more easily customize different workflows for different users/customers.
WF is used by Biztalk for large-scale systems integration and is hosted in-process by many other applications that require the ability to easily modify the orchestration of a number of smaller tasks and actions.
You might want to start with this tutorial on WF4.
HTH.
It's not just plugins or the way how do you technically resolve that plugin problem, use MEF (+1 #laptop) or something else, You got to put most effort in defining plugin "points" in your application, this is gone be most important eg. where you will put that empty "events" to put your code, or what parameters this events or plugins will have.
For example usable plugin would be in before save event, but you will have to have only one place in application that will save various types of business documents, so you can call plugins there and parameter would be abstract document object.
So you have to think real hard about your system architecture, to be abstract enough for various plugin points, and do that architecture completely, don't do just a part of the system and start coding on that.
I hope that you understood what I meant to say, because English is not my native language.
I have a small Utility library containing some useful utility methods which have been fully unit-tested. At the moment, my library has no external dependencies. I am toying with the idea of adding logging to my classes which might be useful for debugging purposes. But this would mean bundling logging libraries along with my project.
My question is: should I keep my library dependency free? Are there any advantages of doing so?
I would add a logging interface that the can be used to abstract the logging. Then the allow users to add logging via this interface. You too should use this interface, and you should supply a 'NullLogger' built into your library that would be used if no other logging is needed.
You can make it easy to not use the NullLogger by asking users to configure a new one, simply by config file or by run time discovery.
Use Java Logging. It's part of JRE/JDK so no external libs are needed.
Check out examples.
There are many advantages of doing so, not the least the ability to run on most any operating system.
One way of keeping your library pretty dependency free, is to require it to initialized prior to use. Then you would in your_lib_init(); function take a function pointer to logging backend. This means, the backend can be rewritten for any platform it might run on.
Also figure out, if you want a library totally free of all library dependencies, or one that depends on the standard class path. If it is pure Java, it will run on J2ME, Android, native compiled Java with GCJ and what not. If it uses class path, it will be portable across all class path implementations, in practice wherever OpenJDK runs.
Pro:
Your library will be much smaller (chances are that you're only using a small part of the full functionality of any dependency)
No update hell (like your code needs library C, version 2, product X needs your code and library C, version 1).
You won't need to bend your spoon to the whims of someone else (say the library you goes from 1.x to 2.x -> you need to update your code)
Con:
Wasted code if product X also needs the library
How smart are you? Chances are that you can't match the thought, wisdom and time that already went into the library.
PS: If you want to support logging, add slf4j to your code; this is a 30KiB API which allows users of your code to use any logging framework out there. Do not use commons-logging.
I'm trying to add plugins to my game and what I'm trying to implement is this:
Plugins will be either mine or 3rd party's so I would like a solution where crashing of the plugin would not mean crashing of the main application.
Methods of plugins are called very often (for example because of drawing of game objects).
What I've found so far:
1) http://www.codeproject.com/KB/cs/pluginsincsharp.aspx - simple concept that seems like it should work nicely. Since plugins are used in my game for every round I would suffice to add the Restart() method and if a plugin is no longer needed Unload() method + GC should take care of that.
2) http://mef.codeplex.com/Wikipage - Managed Extensibility Framework - my program should work on .NET 3.5 and I don't want to add any other framework separately I want to write my plugin system myself. Therefore this solution is out of question.
3) Microsoft provides: http://msdn.microsoft.com/en-us/library/system.addin.aspx but according to a few articles I've read it is very complex.
4) Different AppDomains for plugins. According to Marc Gravell ( Usage of AppDomain in C# ) different AppDomains allow isolation. Unloading of plugins would be easy. What would the performance load be? I need to call methods of plugins very often (to draw objects for example).
Using Application Domains - http://msdn.microsoft.com/en-us/library/yb506139.aspx
A few tutorials on java2s.com
Could you please comment on my findings? New approaches are also welcomed! Thanks!
You can define a public interface which the plugin's must implement. Then with the use of reflection you can scan a "plugin" folder for any classes implementing that interface, then create an instance of that class.
From you're code just work on the interface and call the needed method's. About crashing, always make sure that calls to the "plugin" interface are always encapsulated in a try/catch block. If an exception occurs you can always dispose the plugin
I suspect your two requirements of:
fast performance with drawing objects and
a plugin crash would not crash your app
are going to conflict.
To really ensure a buggy plugin doesn't crash your app, you have to load it in a separate AppDomain (as you've identified already). But you're going to take a performance hit, as the whole point of AppDomains is they isolate instances of objects. So you're, at minimum, going to have to serialize arguments to your plugins (possibly using MarshalByRef objects or Remoting). And I suspect that will mean serializing a good chunk of your game state (which sounds like it at least consists of some sort of image). On the plus side, AppDomains live in the same process space, so the overhead isn't as bad as cross-process communication.
Unloading plugins is as simple as unloading the AppDomain.
Because you have to serialise arguments, you can do validation of your game state after the plugin processes it.
I did some toying with AppDomains once. It takes a few seconds to construct one, in my experience. That may affect how many plugins you load into each AppDomain.
The generalized "secrect" to .NET extensibility is: Dynamic loading (to get the plugin into the AppDomain), Reflection (to verify it supports the methods/interface you specify), Attributes (to get Meta-Data for things like versioning), Late Binding (to actually use the plugin).
If your extensibility needs are very simple, or very unique, you should consider implementing it your way.
I used this tutorial as the basis for my own plug-in architecture a couple of years ago. My architecture was, I believe, a relatively simple architecture, but I hit some problems when it came to passing messages between plug-ins.
If you're intent on writing your own architecture, then fair enough, but I would warn against it. It's no small undertaking, and sooner or later you're going to run into some major design considerations, like message passing, which are non-trivial to solve (if admittedly simultaneously quite interesting and frustrating). There is a tremendous amount of value in using something like MEF that solves these problems for you, and provides a really nice API and framework upon which you can build you plug-ins.
Furthermore, MEF will end up being distributed as part of your application, so you don't need to get your users to download it separately; it's an "invisible" dependency as far as they're concerned, and a light-weight one for developers, including yourself. It's also the official plug-in architecture for Visual Studio 2010, so it has a lot of weight in the .NET community, and there will only ever be more developers able to write plug-ins for your app if you use it too.
Hope that makes some sense.
My company is currently in the process of creating a large multi-tier software package in C#. We have taken a SOA approach to the structure and I was wondering whether anyone has any advice as to how to make it extensible by users with programming knowledge.
This would involve a two-fold process: approval by the administrator of a production system to allow a specific plugin to be used, and also the actual plugin architecture itself.
We want to allow the users to write scripts to perform common tasks, modify the layout of the user interface (written in WPF) and add new functionality (ie. allowing charting of tabulated data). Does anyone have any suggestions of how to implement this, or know where one might obtain the knowledge to do this kind of thing?
I was thinking this would be the perfect corner-case for releasing the software open-source with a restrictive license on distribution, however, I'm not keen on allowing the competition access to our source code.
Thanks.
EDIT: Thought I'd just clarify to explain why I chose the answer I did. I was referring to production administrators external to my company (ie. the client), and giving them someway to automate/script things in an easier manner without requiring them to have a full knowledge of c# (they are mostly end-users with limited programming experience) - I was thinking more of a DSL. This may be an out of reach goal and the Managed Extensibility Framework seems to offer the best compromise so far.
Just use interfaces. Define an IPlugin that every plugin must implement, and use a well defined messaging layer to allow the plugin to make changes in the main program. You may want to look at a program like Mediaportal or Meedios which heavily depend on user plugins.
As mentioned by Steve, using interfaces is probably the way to go. You would need to design the set of interfaces that you would want your clients to use, design entry points for the plugins as well as a plugin communication model. Along with the suggestions by Steve, you might also want to take a look at the Eclipse project. They have a very well defined plugin architecture and even though its written in java, it may be worth taking a look at.
Another approach might be to design an API available to a scripting language. Both
IronPythonand Boo are dynamic scripting languages that work well with C#. With this approach, your clients could write scripts to interact with and extend your application. This approach is a bit more of a lightweight solution compared to a full plugin system.
I would take a look at the MEF initiative from Microsoft. It's a framework that lets you add extensibility to your applications. It's in beta now, but should be part of .Net 4.0.
Microsoft shares the source, so you can look how it's implemented and interface with it. So basically your extensibility framework will be open for everyone to look at but it won't force you to publish your application code or the plug-ins code.
Open source is not necessary in any way shape or form to make a product extensible.
I agree that open source is a scary idea in this situation. When you say approval by a production administrator - is that administrator within your company, or external?
Personally, I would look at allowing extensibility through inheritance (allowing third parties to subclass your code without giving them the source) and very carefully specified access modifiers.
Microsoft already did exactly this, resulting in Reporting Services, which has every attribute you mention: user defined layout, scriptability, charting, customisable UI. This includes a downloadable IDE. No access to source code is provided or required, yet it's absolutely littered with extensibility hooks. The absence of source code inhibits close-coupling and promotes SOA thinking.
We are currently in a similar situation. We identified different scenarios where people may want to create a live connection on a data level. In that case they can have access to a sinle webservice to request and import data.
At some point they may want to have a custom user interface (in our case Silverlight 2). For this scenario we can provide a base class and have them register the module in a central repository. It then integrates into our application in a uniform way, including security, form and behaviour and interaction with services.
I'm fleshing out a WPF business application in my head and one thing that sparked my interest was how I should handle making it incredibly modular. For example, my main application would simply contain the basics to start the interface, load the modules, connect to the server, etc. These modules, in the form of class libraries, would contains their own logic and WPF windows. Modules could define their own resource dictionaries and all pull from the main application's resource dictionary for common brushes and such.
What's the best way to implement a system of this nature? How should the main interface be built so that the modules it loads can alter virtually any aspect of its user interface and logic?
I realize it's a fairly vague question, but I'm simply looking for general input and brainstorming.
Thanks!
Check out Composite Client Application Guidance
The Composite Application Library is designed to help architects and developers achieve the following objectives:
Create a complex application from modules that can be built, assembled, and, optionally, deployed by independent teams using WPF or Silverlight.
Minimize cross-team dependencies and allow teams to specialize in different areas, such as user interface (UI) design, business logic implementation, and infrastructure code development.
Use an architecture that promotes reusability across independent teams.
Increase the quality of applications by abstracting common services that are available to all the teams.
Incrementally integrate new capabilities.
First of all you might be interested in SharpDevelop implementation. It is based on it's own addin system known as AddInTree. It is a separate project and can be used within your own solutions for free. Everything is split across different addins where addins are easily added/removed/configured by means of xml files. SharpDevelop is an open source project so you'll have a chance examining how the infrastructure is introduced, as well as service bus and cross-addin integrations. The core addin tree can be easily moved to WPF project without implications.
Next option is taking "Composite Client Application Guidance" (aka Prism, aka CompositeWPF) already mentioned earlier. You will get the Unity (Object builder) support out-of-box, Event Aggregation as well as the set of valuable design patterns implemented.
If you want to perform some low level design and architecture yourself the MEF will be the best choise (though working with all three I personally like this one). This is what VS 2010 will be based on so you might be sure the project won't lose support in future.
My advice is elaborating on these approaches and selecting the best and efficient one that perfectly suits your needs and the needs of your project.
Have a look at Prism