from last couple of days I was reading about the PRISM, CAL & MEF. All of these support the composition, modularity, bootstrapers, shell and region etc.
So question comes in my mind is. Where these all support main features for modularity so which framework to use and where they fit best.
can somebody guide me for the comparing these techs?
CAL was an old name for PRISM that is no longer in use. PRISM uses MEF, Unity or any other inversion of control library to implement composition and dependency injection. MEF is newer and easier to work with than Unity, but it all depends on the templates you decide to use.
Perhaps you should check the Developer's Guid to Prism for a better understanding of PRISM. PRISM's use of IoC/DI is described in Modular Application Development/Dependency Injection and Modular Applications
You should also note that PRISM is considered over-engineered, even if you think your application fits the Composite Application definition (it probably doesn't).
It is much easier to get up to speed with MVVM and WPF development if you use a simpler framework like Caliburn.Micro or MVVM Light.
CAL is a former name of Prism framework. MEF is a IoC container (one of them). Prism can use different IoC containers (Unity and MEF out of the box).
So, your question doesn't makes any sense.
Can you please provide me with some tips/guidelines when architecting, designing and implementing a .net framework application, with the requirements given below:
It will be an analytical tool which will retrieve data from files, sql databases and may be cubes. So data layer should be able to handle that. The middleware should be totally independent of the other layers so probably need an IoC container (which one would you recommend)
It will be deployed on the local intranet
The front layer might be WPF application or Silverlight in future (for now, I am concentrating on Silverlight but the point is that it will change)
It should be easy to customise and improve it in the future without changing much of the code as the framework will be deployed for many clients
I need a way to store the configuration information, which will be picked up by the application on application load events to set its feel and look.
I have two months to implement it and looking for as many tips as possible.
SoC for a start
break your application into several assemblies that use IoC (interfaces + implementations):
application model assembly - all other assemblies will reference this one because these classes will be used for inter-communication - they will mostly be just POCOs
presentation assembly - references app model and business services - this one is either WPF or Silverlight in any case use MVVM to make your testing life easier
business services assembly - references app model and data repositories assembly
data repositories - these define repositories that actually get data from the stores
Then I'd create three additional ones:
file data providers
database providers
cube providers
Data repositories would reference all three and use them to provide necessary data.
If configuration becomes very complex with a lot of functionality then you should put it in a separate assembly as well and reference it by business services assembly.
Which MVVM library to use
Since you mentioned time I suppose you'll have hard time catching your deadline. When using MVVM (which I suggested to use) I also suggest you don't use a full blown PRISM (a.k.a. Composite Application Guidance from P&P) but rather go with MVVM Light Toolkit. It will take you less time to get on the bandwagon.
Code generation
In places where appropriate I suggest you use T4 to its full potential. I use it to import stored procedure calls to avoid using magic strings when calling stored procedures (and using their parameters). Check my blog post about it as well.
DAL technology/library
Don't write your own data access code using things like SqlConnection/SqlConnection functionality. There're many data access layer libraries/technologies today that you can use and not reinvent the wheel. If you know nHibernate, then use that. If you know EF, then use that. If you know anything else, use that. Anything that will provide/generate as much code for you as possible that is already tested and debugged.
So it all boils down to:
DRY + YAGNI
a.k.a. Don't repeat yourself and You ain't gonna need it = don't over-engineer you code.
Agile developers are supposed to be lazy
They should develop just as much as it's needed and no more! TDD implicitly provides this process by the red => green => refactor steps.
I would recommend using MVVM and Test Driven Development. The MVVM will give you good separation between the front and middleware, and the TDD will help control the chaos that comes with any nontrivial app development.
Have a look at the Composite Application Guidance from Microsoft's Patterns and Practices group, it may not match what you are doing exactly but will give you some good ideas.
From an architectural standpoint, I highly recommend taking a look at the Microsoft Application Architecture Guide. Since you are already using the Microsoft technology stack, I would consider using Microsoft Unity for IoC. You indicated that your presentation layer might use WPF or Silverlight, so take a look at using Windows Communication Foundation, as you will be somewhat constrained in Silverlight when it comes to communication with your data layer.
My application should be extensible. For my own needs I have implement some services. These services are based on the IoC/DI princple. So the services encapsulate the concept of the application.
For exsample, there are an IApplicationService. The ApplicationService exposes information about the current exceuting application. There are specified the AssemblyInfo and so forth. An other exsample is the INavigationService(see mef.codeplexcom in the samples). This services provides some properties where are information about the current selected item specified and also some events.
I think, that the "service approach" is the easiest and simplifies the extension points for the application. So, I am not sure that this is really the best approach. What do you think? How do you would implement "extensions points" in an application like addins/addons/plugins ... ?
Thanks in advance for your replies! And sorry, my english is poor. ;)
Are you familiar with MEF (Managed Extensibility Framework)?
The Managed Extensibility Framework (or MEF for short) simplifies the creation of extensible applications. MEF offers discovery and composition capabilities that you can leverage to load application extensions.
You seriously need to look at MEF - the Managed Extensibility Framework.
Managed Extensibility Framework Overview
Building Composable Apps in .NET 4 with the Managed Extensibility Framework
MEF on Codeplex
It's a great new framework that Microsoft itself is using in e.g. Visual Studio 2010 for its extensibility story. Great and easy to use - why reinvent the wheel when you can use something that thousands of dev will use shortly??
Yes, I am familiar with MEF. I also use the concept of MEF, but there some disadvantages. My application is IoC/DI like and together with MEF is a bit complicated. MEF is not really a DI container so to use MEF with an other DI container(e.g. ninject, unity, ...) is difficult to implment this. I won't to use MEF with other DI containers. So to mix MEF with other DI containers is not really good.
I hope you can understand my concern.
Addition: It is not possible to load extensions in to an AppDomain in MEF. So this is for my needs not good. System.AddIn or MAF supports this, but I won't use System.AddIn, because this is very heavy ... .
I've got a plugin that needs access to certain information in order to populate its GUI elements properly. However, this plugin should not know about all other plugins, so I want it to request this information from the application.
In situations like this, I always create an interface for data exchange, and then pass this interface to plugins so that they can request the data when it's needed. However, I recently started to use the MVVM light toolkit because it's got some great features like RelayCommand and Messenger. In this case, I can totally see using Messenger -- plugins don't need the interface, because they can simply use Messenger.Default.Send<MyDataRequestMessage>(...). As long as they register the Receive handler, it's all good... or is it?
Which method would you favor, and why?
In case of plugins, an aggregator like MVVM Light's messenger is quite alright; alternatively, you could look at MEF (now part of .Net 4), which also enables auto-discovery and other such nice features, and you could use interfaces with that. So the answer is it depends :) Personally I'd favor Messenger for its simplicity, unless it's for a very large enterprise-y project maybe.
As Alex said, MEF was created just for this purpose. If you need to manage plug-ins, you're probably going to end up duplicating a lot of work that MEF provides for you if you don't use it.
There's no reason you can't use both MEF and MVVM Light. Your idea of communicating from your plug-in to your app using MVVM light's messenger is intriguing, and I hope it works for you. However, keep in mind that any plug-in could register to receive these same messages and you could end up with one plug-in receiving another plug-in's messages. This might not be an issue for you, but if you don't control who writes these extensions you definitely have a security hole there.
Good luck!
As it currently stands, this question is not a good fit for our Q&A format. We expect answers to be supported by facts, references, or expertise, but this question will likely solicit debate, arguments, polling, or extended discussion. If you feel that this question can be improved and possibly reopened, visit the help center for guidance.
Closed 10 years ago.
Which C#/.NET Dependency Injection frameworks are worth looking into?
And what can you say about their complexity and speed.
edit (not by the author): There is a comprehensive list of IoC frameworks available at https://github.com/quozd/awesome-dotnet/blob/master/README.md#ioc:
Castle Windsor - Castle Windsor is best of breed, mature Inversion of Control container available for .NET and Silverlight
Unity - Lightweight extensible dependency injection container with support for constructor, property, and method call injection
Autofac - An addictive .NET IoC container
DryIoc - Simple, fast all fully featured IoC container.
Ninject - The ninja of .NET dependency injectors
Spring.Net - Spring.NET is an open source application framework that makes building enterprise .NET applications easier
Lamar - A fast IoC container heavily optimized for usage within ASP.NET Core and other .NET server side applications.
LightInject - A ultra lightweight IoC container
Simple Injector - Simple Injector is an easy-to-use Dependency Injection (DI) library for .NET 4+ that supports Silverlight 4+, Windows Phone 8, Windows 8 including Universal apps and Mono.
Microsoft.Extensions.DependencyInjection - The default IoC container for ASP.NET Core applications.
Scrutor - Assembly scanning extensions for Microsoft.Extensions.DependencyInjection.
VS MEF - Managed Extensibility Framework (MEF) implementation used by Visual Studio.
TinyIoC - An easy to use, hassle free, Inversion of Control Container for small projects, libraries and beginners alike.
Stashbox - A lightweight, fast and portable dependency injection framework for .NET based solutions.
Original answer follows.
I suppose I might be being a bit picky here but it's important to note that DI (Dependency Injection) is a programming pattern and is facilitated by, but does not require, an IoC (Inversion of Control) framework. IoC frameworks just make DI much easier and they provide a host of other benefits over and above DI.
That being said, I'm sure that's what you were asking. About IoC Frameworks; I used to use Spring.Net and CastleWindsor a lot, but the real pain in the behind was all that pesky XML config you had to write! They're pretty much all moving this way now, so I have been using StructureMap for the last year or so, and since it has moved to a fluent config using strongly typed generics and a registry, my pain barrier in using IoC has dropped to below zero! I get an absolute kick out of knowing now that my IoC config is checked at compile-time (for the most part) and I have had nothing but joy with StructureMap and its speed. I won't say that the others were slow at runtime, but they were more difficult for me to setup and frustration often won the day.
Update
I've been using Ninject on my latest project and it has been an absolute pleasure to use. Words fail me a bit here, but (as we say in the UK) this framework is 'the Dogs'. I would highly recommend it for any green fields projects where you want to be up and running quickly. I got all I needed from a fantastic set of Ninject screencasts by Justin Etheredge. I can't see that retro-fitting Ninject into existing code being a problem at all, but then the same could be said of StructureMap in my experience. It'll be a tough choice going forward between those two, but I'd rather have competition than stagnation and there's a decent amount of healthy competition out there.
Other IoC screencasts can also be found here on Dimecasts.
It depends on what you are looking for, as they each have their pros and cons.
Spring.NET is the most mature as it comes out of Spring from the Java world. Spring has a very rich set of framework libraries that extend it to support Web, Windows, etc.
Castle Windsor is one of the most widely used in the .NET platform and has the largest ecosystem, is highly configurable / extensible, has custom lifetime management, AOP support, has inherent NHibernate support and is an all around awesome container. Windsor is part of an entire stack which includes Monorail, Active Record, etc. NHibernate itself builds on top of Windsor.
Structure Map has very rich and fine grained configuration through an internal DSL.
Autofac is an IoC container of the new age with all of it's inherent functional programming support. It also takes a different approach on managing lifetime than the others. Autofac is still very new, but it pushes the bar on what is possible with IoC.
Ninject I have heard is more bare bones with a less is more approach (heard not experienced).
The biggest discriminator of Unity is: it's from and supported by Microsoft (p&p). Unity has very good performance, and great documentation. It is also highly configurable. It doesn't have all the bells and whistles of say Castle / Structure Map.
So in summary, it really depends on what is important to you. I would agree with others on going and evaluating and seeing which one fits. The nice thing is you have a nice selection of donuts rather than just having to have a jelly one.
Autofac. https://github.com/autofac/Autofac It is really fast and pretty good. Here is a link with comparisons (made after Ninject fixed a memory leak issue).
http://www.codinginstinct.com/2008/05/ioc-container-benchmark-rerevisted.html
Ninject is great. It seems really fast, but I haven't done any comparisons. I know Nate, the author, did some comparisons between Ninject and other DI frameworks and is looking for more ways to improve the speed of Ninject.
I've heard lots of people I respect say good things about StructureMap and CastleWindsor. Those, in my mind, are the big three to look at right now.
I use Simple Injector:
Simple Injector is an easy, flexible and fast dependency injection library that uses best practice to guide your solutions toward the pit of success.
I'm a huge fan of Castle. I love the facilities it also provides beyond the IoC Container story. It really simplfies using NHibernate, logging, AOP, etc. I also use Binsor for configuration with Boo and have really fallen in love with Boo as a language because of it.
I spent the better part of a day struggling without success to get the simplest Spring.NET example working. Could never figure out how to get it to find my assembly from the XML file. In about 2 hours, on the other hand, I was able to get Ninject working, including testing integration with both NUnit and MSTest.
I've used Spring.NET in the past and had great success with it. I never noticed any substantial overhead with it, though the project we used it on was fairly heavy on its own. It only took a little time reading through the documentation to get it set up.
I can recommend Ninject. It's incredibly fast and easy to use but only if you don't need XML configuration, else you should use Windsor.
The great thing about C# is that it is following a path beaten by years of Java developers before it. So, my advice, generally speaking when looking for tools of this nature, is to look for the solid Java answer and see if there exists a .NET adaptation yet.
So when it comes to DI (and there are so many options out there, this really is a matter of taste) is Spring.NET. Additionally, it's always wise to research the people behind projects. I have no issue suggesting SourceGear products for source control (outside of using them) because I have respect for Eric Sink. I have seen Mark Pollack speak and what can I say, the guy just gets it.
In the end, there are a lot of DI frameworks and your best bet is to do some sample projects with a few of them and make an educated choice.
Good luck!
I think a good place to start is with Ninject, it is new and has taken into account alot of fine tuning and is really fast. Nate, the developer, really has a great site and great support.
Spring.Net is quite solid, but the documentation took some time to wade through. Autofac is good, and while .Net 2.0 is supported, you need VS 2008 to compile it, or else use the command line to build your app.