ASP.NET MVC IoC usability

How often do you use IoC for controllers/DAL in real projects?

IoC allows to abstract application from conc开发者_运维知识库rete implementation with additional layer of interfaces that should be implemented. But how often concrete implementation changes? Should we really have to do job twice adding method to interface then the implementation if implementation hardly will ever be changed? I took part in about 10 asp.net projects and DAL (ORM-like and not) was never rewritten completely.

Watching lots of videos I clearly understand that IoC "is cool" and the really nice way to program, but does it really needed?

Added a bit later: Yes, IoC allows prepare better testing environment, but we also have nice way to test DAL without IoC. We wrap DAL calls to database into uncommited transactions without risk to make data unstable.

---

IoC isn't a pattern only for writing modular programs; it also allows for easier testing, by being able to swap in mock objects that implement the same interface as the components they stand in for.

Plus, it actually makes code much easier to maintain down the road.

---

It's not IOC that allows you to abstract application from concrete implementation with additional layer of interfaces, this is how you should design your application in order to be more modular and reusable. Another important benefit is that once you've designed your application this way it will be much easier to test the different parts in isolation without depending on concrete database access for example.

---

There's much more about IoC except ability to change implementation:

• testing
• explicit dependencies - not hidden inside private DataContext
• automatic instantiation - you declare in constructor that you need something, and you get it - with all deep nested dependencies resolved
• separation of assemblies - take a look at S#arp Architecture to see how IoC allows to avoid referencing NHibernate and other specific assemblies, which otherwise you'll have to reference
• management of lifetime - ability to specify per request / singleton / transitive lifetime of objects and change it in one place, instead of in dozens of controllers
• ability to do dynamic stuff, like, getting correct data context in model binders, because with IoC you now have metadata about your dependencies; and this shows that maybe IoC does to your object dependencies what reflection does to C# programming - a lot of new possibilities, that you never even thought about

And so on, I'm sure I missed a lot of positive stuff. While the only "bad" thing that I can think about (and that you mentioned) is duplication of interface, which is non-issue with modern IDEs support for refactoring.

Well, if your data interfaces change every day, and you have hundreds of them - you may want to avoid IoC.

But, do you avoid good design practices just because it's harder to follow them? Do you copy and paste code instead of extracting a method/class, just because it takes more time and more code to do so? Do you place business logic in views just because it's harder to create view models and sync them with domain models? If yes, then you can avoid IoC, no problem.

---

You're arguing that using IOC takes MORE code than not using it. I disagree.

Here is the entire DAL IOC configuration for one of my projects using LinqToSql. The ContextProvider class is simply a thread safe LinqToSql context factory.

container.Register(Component.For<IContextProvider<LSDataContext>, IContextProvider>().LifeStyle.PerWebRequest.ImplementedBy<ContextProvider<LSDataContext>>();
container.Register(Component.For<IContextProvider<WorkSheetDataContext>, IContextProvider>().LifeStyle.PerWebRequest.ImplementedBy<ContextProvider<WorkSheetDataContext>>();
container.Register(Component.For<IContextProvider<OffersReadContext>, IContextProvider>().LifeStyle.PerWebRequest.ImplementedBy<ContextProvider<OffersReadContext>>();

Here is the entire DAL configuration for one of my projects using NHibernate and the repository pattern:

container.Register(Component.For<NHSessionBuilder>().LifeStyle.Singleton);
container.Register(Component.For(typeof(IRepository<>)).ImplementedBy(typeof(NHRepositoryBase<>)));

Here is how I consume the DAL in my BLL (w/ dependency injection):

public class ClientService
{
    private readonly IRepository<Client> _Clients;


public ClientService(IRepository&lt;Client&gt; clients)
{
    _Clients = clients;
}

public IEnumerable&lt;Client&gt; GetClientsWithGoodCredit()
{
    return _Clients.Where(c => c.HasGoodCredit);
}


}

Note that my IRepository<> interface inherits IQueryable<> so this code is very trivial!

Here's how I can test my BLL without connecting to a DB:

public void GetClientsWithGoodCredit_ReturnsClientWithGoodCredit()
{
    var clientWithGoodCredit = new Client() {HasGoodCredit = true};
    var clientWithBadCredit = new Client() {HasGoodCredit = false};
    var clients = new List<Client>() { clientWithGoodCredit, clientWithBadCredit }.ToTestRepository();
    var service = new ClientService(clients);


var clientsWithGoodCredit = service.GetClientsWithGoodCredit();

Assert(clientsWithGoodCredit.Count() == 1);
Assert(clientsWithGoodCredit.First() == clientWithGoodCredit);


}

ToTestRepository() is an extension method that returns a fake IRepository<> that uses an in-memory list.

There is no possible way you can argue that this is more complicated than newing up your DAL all over your BLL.

The only way you could have ever written the above test is by connecting to a DB, saving some test clients, and then querying. I guarantee that takes 100+ times longer to execute than this did. (Times that by 1000 tests and you can go get some coffee while you're waiting.)

Also, by using uncommitted transactions for testing you introduce debugging nightmares resulting from ORMs that don't query over uncommitted entities.