IoC Frameworks just make DI much easier, but it's not only DI that they do, they provide a host of other benefits over and above DI.
I saw this comment in one of the answers to a question about DI and IoC. Can someone explain this in some more details? What are other benefits of IoC?
Dependency injection is where a component (A) requires the basic functionality simliar to Component B, but does not directly state it. Inversion of control frameworks just highly depend on DI, rather than make assumptions of what is needed. Alternative components can be developed to replace the default implementation needed with dependency injection. Also another benefit of this is that the code is loosely couple, thus easier to reuse, reconfigure, and (typically) debug.
Related
All the articles and papers about this subject, provide overly simplistic examples. The concepts are easy to understand. However, without substantial experience (both myself and my teammates) in this subject, it is not trivial to map the concepts to actual design decisions in a real life system. No way to validate my architecture.
Can anyone provide me with a real system implementation, that correctly implements IoC.
Note: I am not talking about dependency injection. I'm currently using a container, and I use system wide injection. I am more interested in the way code is kept decoupled, i.e., how is library separation performed (to what extent), and how and where is the interface/contract code declared and included.
Thanks
The open-source GlassFish application server (https://glassfish.java.net/) uses hk2 (https://hk2.java.net) as a DI container. It has several areas where implementations are kept separate from contracts, and where in fact implementations of those contracts can be dynamically added or removed while the server is up and running.
For example take a look at the command-line (asadmin) facility. Users can deploy OSGi bundles that can add new implementations of the command-line contract which will then dynamically be added to the set of things asadmin can do. This is a good example of how to use IoC in order to keep your contracts and services separated.
It is also instructive in that GlassFish was not originally designed with a DI container, so it is a good real-world use case for how to add DI/IoC into systems that were not originally designed in that way.
I have recently learned of the Repository and Unit of Work Design Patterns and thought that I would implement them in a new EF4 MVC3 project, since abstraction is generally good.
As I add them to the project, I am wondering if the juice is worth the proverbial squeeze, given the following:
It is EXTREMELY unlikely that the underlying data access mechanism will change from EF4.
This level of abstraction will require more overhead/confusion to the project and to other developers on the team.
The only real benefit I see to using the Repository pattern is for unit testing the application. Abstracting away the data store doesn't seem useful since I know the datastore won't change, and further, that EF4 already provides a pretty good abstraction (I just call .AddObject() and it looks like I am modifying an in-memory collection and I just call .SaveChanges() which already provides the unit of work pattern).
Should I even bother implementing this abstraction? I feel like there must be some massive benefit that I am missing, but it just doesn't feel like I need to go down this route. I am willing to be convinced otherwise; can someone make a case? Thanks.
I recommend you reading this answer and all linked questions. The repository is very popular pattern and it really makes your application nice and clean. It make you feel that your architecture is correct but some assumptions about repository pattern with EF are not correct. In my opinion (described in those answers):
It will make some more complex EF related task much harder to achieve or your repository and UoW implementation will need to have public interface very similar to EF's
It will not make your code better unit testable because all interactions with repository must still be covered by integration tests. Not only my experience proved that mocking EF code by replacing linq-to-entities with linq-to-objects does not test your code.
yes yes yes : ) - first of all - the repository pattern helps to inject your dependencies for unit testing. Secondly, it gives a very clear view of exactly what data access methods are available to get something rather than people misc. coding against the EF layer directly. Download the POCO templates though for EF4 so your classes don't carry the EF properties around with them if you happen to use them as models and/or don't want any EF dependency libraries references in your mvc app assuming your repository work is in a separate project (which I recommend). If you are using all viewmodels then its not as much of a concern, but its nice working with a "Customer" object without extra methods on them. Its cleaner in my opinion.
I have a relatively basic question but more than anything just need some clarity really, I have been using Prism (Composite Application Guidance) to create a WPF MVVM desktop application in C#, this bit I am all clear about (or so I thought) along with IoC and Module based architecture etc. At the same time I have started using MEF and realise that there is a kind of grey area between the two (I have found and read a number of articles/blogs on hosting MEF Extensions in IoC containers and the like.
However....recently I have started looking at Enterprise Library 5 and this is whats led to my confusion. Where do they all fit together? So Prism uses DI with a Module based architecture... EntLib uses Di with an Application Block type architecture... and MEF doesn't use DI at all? Does this mean that EntLib and Prism are entirely separate architectual methods or that one is a subset of the other? Also could MEF be used with either/both?
Any explanation would be most welcome.
Many thanks
I, too, was puzzled by the difference between IoC and MEF. The simplest way I found to describe them, was this:
MEF is for discovering and instantiating something you don't know about.
IoC is for requesting something you do know about.
A little bit of context. MEF will always instantiate the import that you request at least once. You are not capable of creating it yourself, and putting it into the catalogue ready to be used. MEF is responsible for creating and satisfying the imports. Dynamically loaded DLLs, where you don't know which DLLs are arriving, is a good example.
IoC on the other hand - you request an implementation from the current library, and you are given one. But you are also responsible for ensuring that an implementation exists.
IoC is for dependency injection. MEF is for extensibility.
Take a look at these 2 posts:
Should I use MEF for my general IoC needs?
Prism and MEF
As to Enterprise Library, in v5.0 we've made it container-agnostic. Even though Enterprise Library ships with Unity container out-of-the-box, it is architected to work with any container of your choice or MEF. You do need to provide an appropriate configurator (see info on configurators at the end of this summary)
My company needs to rewrite a large monolithic program, and I would want it written using a plugin type architecture. Currently the best solution appears to be MEF, but as it is a fairly 'new' thing I am warey of betting the future of my company (and my reputation) on it.
Does anyone have a feeling on how mature a solution MEF is ?
Thanks
Visual Studio's entire extension system is now built on MEF.
That is to say that Microsoft is Dog-fooding it (like they are doing with WPF).
Given that the framework developers themselves will be working with it, you can feel pretty confident that it is here to stay. However, as with any first release, you are almost guaranteed to have some growing pains when the next release comes around.
Personally, I would go for it. It is certainly better than the tightly-coupled-reflection-based alternative.
I don't think it is necessary to "bet on MEF". Your code should have very little dependencies on MEF.
You can use the technique of dependency injection to break up your monolithic application into components which have only a single responsibility, and which limit their knowledge of other components to abstractions. See this blog post by Nicholas Blumhardt for a nice overview of the type of relations that can exist between components.
Wiring the components together into an application can then be done with any dependency injection framework, or even manually. The component logic shouldn't need to be aware of the container - there might not even be a container.
In the case of MEF, you do need to add import/export attributes to your classes. However, you can still ignore those attributes and reuse those components without MEF, e.g. by using another DI framework like AutoFac.
It's a relatively new technology, so I'm not sure if it's exactly mature. I'm sure it will change quite a bit over the next several years, perhaps merging with other frameworks to better support IoC. That said, MS has a pretty good history of preserving backwards compatibility, so now that MEF is actually part of the Framework, I would consider the public interfaces stable.
That said, MEF might not actually be the right solution for your project. It depends on your extensibility needs and how large is 'large'. If you want to support true extensibility, including the possibility for third-party plugins, it has an enormous impact on your design responsibilities. It's much harder to make changes to the infrastructure as you now need to maintain very stable public interfaces. If you're really only after the IoC features, you're probably better off with a true IoC framework, which more clearly limits your design responsibility to support of your internal dependencies. If you're betting the future of the company, this is the bigger question, in my mind.
Looking at Microsoft's Managed Extensibility Framework (MEF) and various IoC containers (such as Unity), I am failing to see when to use one type of solution over the other. More specifically, it seems like MEF handles most IoC type patterns and that an IoC container like Unity would not be as necessary.
Ideally, I would like to see a good use case where an IoC container would be used instead of, or in addition to, MEF.
When boiled down, the main difference is that IoC containers are generally most useful with static dependencies (known at compile-time), and MEF is generally most useful with dynamic dependencies (known only at run-time).
As such, they are both composition engines, but the emphasis is very different for each pattern. Design decisions thus vary wildly, as MEF is optimized around discovery of unknown parts, rather than registrations of known parts.
Think about it this way: if you are developing your entire application, an IoC container is probably best. If you are writing for extensibility, such that 3rd-party developers will be extending your system, MEF is probably best.
Also, the article in #Pavel Nikolov's answer provides some great direction (it is written by Glenn Block, MEF's program manager).
I've been using MEF for a while and the key factor for when we use it instead of IOC products is that we regularly have 3-5 implementations of a given interface sitting in our plugins directory at a given time. Which one of those implementations should be used is actually something that can only be decided at runtime.
MEF is good at letting you do just that. Typically, IOC is geared toward making sure you could swap out, for a cononical example, an IUserRepository based on ORM Product 1 for ORM Product 2 at some point in the future. However, most IOC solutions assume that there will only be one IUserRepository in effect at a given time.
If, however, you need to choose one based on the input data for a given page request, IOC containers are typically at a loss.
As an example, we do our permission checking and our validation via MEF plugins for a big web app I've been working on for a while. Using MEF, we can look at when the record's CreatedOn date and go digging for the validation plugin that was actually in effect when the record was created and run the record BOTH through that plugin AND the validator that's currently in effect and compare the record's validity over time.
This kind of power also lets us define fallthrough overrides for plugins. The apps I'm working on are actually the same codebase deployed for 30+ implementations. So, we've typically go looking for plugins by asking for:
An interface implementation that is specific to the current site and the specific record type in question.
An interface implementation that is specific to the current site, but works with any kind of record.
An interface that works for any site and any record.
That lets us bundle a set of default plugins that will kick in, but only if that specific implementation doesn't override it with customer specific rules.
IOC is a great technology, but really seems to be more about making it easy to code to interfaces instead of concrete implementations. However, swapping those implementations out is more of a project shift kind of event in IOC. In MEF, you take the flexibility of interfaces and concrete implementations and make it a runtime decision between many available options.
I am apologizing for being off-topic. I simply wanted to say that there are 2 flaws that render MEF an unnecessary complication:
it is attribute based which doesn't do any good to helping you figuring out why things work as they do. There's no way to get to the details burred in the internals of the framework to see what exactly is going on there. There is no way to get a tracing log or hook up to the resolving mechanisms and handle unresolved situations manually
it doesn't have any troubleshooting mechanism to figure out the reasons for why some parts get rejected. Despite pointing at a failing part it doesn't tell you why that part has failed.
So I am very disappointed with it. I spent too much time fighting windmills trying to bootstrap a few classes instead of working on the real problems. I convinced there is nothing better than the old-school dependency injection technique when you have full control over what is created, when, and can trace anything in the VS debugger. I wish somebody who advocates MEF presented a bunch of good reasons as to why would I choose it over plain DI.
I agree that MEF can be a fully capable IoC framework. In fact I'm writing an application right now based on using MEF for both extensibility and IoC. I took the generic parts of it and made it into a "framework" and open sourced it as its own framework called SoapBox Core in case people want to see how it works.
In particular, take a look at how the Host works if you want to see MEF in action.