K
K
kid-programmer2014-02-02 19:54:14
ASP.NET
kid-programmer, 2014-02-02 19:54:14

ASP MVC and Ninject or other ioc. How to use, organize the structure?

Hello. Can't figure out the correct way to use Ninject in MVC. Immediately make a reservation that I'm just learning and maybe I did not understand everything correctly. They write and say what needs to be done according to Feng Shui (correctly), namely, to separate the project assemblies into layers and so that these layers depend on the interfaces.
For example:
1. Infrastructure.Domain layer (any interfaces IEntity, IUnitOfWork, IQueryFactory)
2. Domain layer (Project entities (User, Role, News, Comment ) + implementation of a couple of interfaces from 1)
3. Domain.EF layer (implementation of interfaces from 1 under the Entity Framework form)
4. WebUI layer (mvc framework itself)
As I understand it, the last layer should depend only on the Infrastructure.Domain interfaces, well, we can also from the Domain (there are entities) ... but the implementation of the remaining interfaces must be done through ninject. But it turns out that ninject itself is used in mvc, and in order for it to see the implementation, you need to connect the Domain.EF assembly. As a result, the mvc layer depends on all other layers, since you need to specify them ninject. How to organize all this business? What is the structure of layers, assemblies in your projects (typical)? How to work with them through the ioc container?
ps since ioc containers can be used differently, it can create a layer purely for using them, do you have any ideas or is this not right?

Answer the question

In order to leave comments, you need to log in

3 answer(s)
K
kid-programmer, 2014-02-03
@kid-programmer

I retired to read)) Only it is better to buy a book.

F
fart, 2014-02-02
@fart

take a look here , it might help

M
Mykola Dzedzinskyi, 2014-02-03
@dzedzinskiy

Ninject is useful in large projects where there is strong coupling to a particular implementation. Those. if at some time you need to replace some class, then you do not have to edit the dependent code (and there can be many such places), modules are associated with interfaces that you associate with specific implementations in the DependencyResolver.
If you need to change the implementation of a class, you will need to change the association of the interface with the final implementation of the class in one place of the DependencyResolver.
As a result, your code should have no object creation records, only their interfaces.
And at the expense of connecting / deleting assemblies - this is another topic. The essence of using ninject does not apply to this.

Didn't find what you were looking for?

Ask your question

Ask a Question

731 491 924 answers to any question