I am looking for a simple but practical and reliable IOC / DI structure for .net

I'm going to use it in a project with less experienced developers, so a complex structure like Spring.NET is not an option. I'm thinking of:

  • Ninject
  • Windsor castle
  • Structuremap

What is a moderate learning curve without losing flexibility?

and one more question - where to place the configuration correctly? Since the kernel / configuration is on a three-tier ASP.NET application (and not MVC !!! all examples use MVC :))

+3
source share
11 answers

The great thing about using DI properly is that you can defer the decision about which DI container to use until the last crucial moment . In terms of application architecture, this corresponds to the so-called root composition in which you connect all the relationships. This is often the entry point to the application .

In addition to Root Composition, an entire application can be recorded without reference to any particular DI container at all. You just need to follow famous patterns and principles .

When it comes to choosing a DI container, I know about these DI containers for .NET:

Personally, I have still been pleased with Castle Windsor, but I have yet to gain extensive experience in all of these containers.

+4
source

I used ninject and found it easy to get new developers up to speed.

0
source

Consider starting with manual posting: see http://blog.objectmentor.com/articles/2010/01/17/dependency-injection-inversion . This gives less experienced developers a better understanding of the basics of IOC / DI.

0
source

I think you are too hasty to reject spring.net. Spring offers an extremely flexible learning curve, so at the beginning it’s a kind of “you take what you want from it” approach.
You can start with the simplest IoC container, and then switch to aop, transactions, unit testing or whatever, so that the complexity gradually grows.

It was No. 1 sale number in my last two works for using spring. Additional items:

  • It does not force you to use its api or bend your architecture. Again, this forces you to adapt your capabilities at your own pace.
  • Very extensive documentation.

When the project matures, so will your developers, so Spring will be useful at the end ... (free, in my opinion, at the beginning)

0
source

In addition to Ninject, which is a great product, there are also two other options that I'm familiar with:

  • Microsoft Unity Some people at Alt.NET find this a bit big and complicated. I have been using it for several months as part of Prism (Prism is NOT required to use Unity, it is available separately), and I found it simple and straightforward.
  • StructureMap . I found that StructureMap also has a very soft learning curve with fast rise.

Hope this helps.

0
source

Autofac is my container of choice. It allows you to register using lambda expressions for maximum flexibility (the link has some good examples).

It also has a Silverlight compatible version. I am not sure what the other containers are.

As for placement, a container must be created at application startup time. For an ASP.NET application, this will be in the Global.Application_Start method.

Autofac has ASP.NET integration that embeds page instances using the container that you create at startup.

0
source

Take a look at http://funq.codeplex.com/ , first of all, it is very fast compared to windsor and other reflection-based containers. all this is very flexible, but still has a very readable configuration (if you got your head around Lamba expressions, which should last by any means)

0
source

We use a managed extensibility infrastructure . It is part of the .NET 4.0 platform (currently in the release candidate), where you can find it in the System.ComponentModel.Composition namespace. The Codeplex site is currently still the best source of documentation.

MEF focuses more on “extensibility” rather than “dependency injection”, but dependency injection is used for this. For example, the Visual Studio 2010 code editor uses MEF to provide extensibility.

We use it as a DI structure and have not yet encountered any problems (although I need a dynamic instance that is not part of the kernel yet).

0
source

If you are still familiar with any DI card, I would go with Simple Injector .

It has a very simple API to help you get started very quickly. Despite its simplicity, it still allows the use of an advanced configuration script . A library designed with migration in mind, which means that switching to another structure will be quite simple. To prove this, there is a guide to migrating to the project wiki .

0
source

I find StructureMap to be very useful and intuitive to use. I played around a bit with Ninject and found this less convenient, but YMMV. I would also recommend using a common service locator as an intermediary between the actual implementation of your IOC and your application. When you want to switch your IOC / DI container later, it will be less painful. Adapters exist for StructureMap and Windsor Castle. And I think that from googling there is also an adapter for Ninject 2 according to this.

-2
source

Source: https://habr.com/ru/post/1341354/


All Articles