How to implement IDependencyResolver in an N-tier layer application?

Question

I have a three-layered application. Each of parts have dependencies from another part of my solution. I used to implement IDependencyResolver inside of MVC project. This is a wrong way, because it leads to violating the architectural rules of layer separation. My MVC project had reference to DAL layer. It's a bad coding practices. I know that I can create a separate class library project. It will has references to any other projects of my solution. It will resolve all dependencies. I heard that it not the best way. There is a better way. Each projects of my solution should resolve it owns dependencies. I don't understand how to put it all together. So I found this useful article: Dependency Injection Best Practices in an N-tier Modular Application but it seems too difficult and complex. Is there another way? I have a similar structure of solution. UserRepository returns a requsted user.

public interface IUserRepository
    {
        IEnumerable<UserEntity> GetAll();
    }

    public class UserRepository : IUserRepository
    {
        public IEnumerable<UserEntity> GetAll()
        {
            // some code
        }
    }

UserService can has a few different dependencies.

public interface IUserService
    {
        IEnumerable<UserModel> GetAll();
    }

    public class UserService : IUserService
    {
        private readonly IUserRepository userRepository;
        private readonly ISecondRepository secondRepository;
        private readonly IThirdRepository thirdRepository;

        public UserService(IUserRepository userRepository, ISecondRepository secondRepository, IThirdRepository thirdRepository)
        {
            this.userRepository = userRepository;
            this.secondRepository = secondRepository;
            this.thirdRepository = thirdRepository;
        }

        public IEnumerable<UserModel> GetAll()
        {
            // some code
        }
    }

And finally UserController constructor might has a lot of different dependencies.

My question is about what is the right and the simplest way to resolve these dependencies avoiding violating the architectural rules?

Answer 1

Like you said you can create additional layer which will compose dependencies, this is called composition root Check this SO question . In your case the composition root is the MVC project. From my point of view referencing the DAL is not that bad practice. There is line should be drawn when we are speaking of dependencies. For me when we talk about dependencies is not that important the dll reference but the type(interface or concrete) that is used. As you know DI is about depending on abstraction where it has actual value. So your code is still ok, as long as you depend only on the interfaces in the DAL.

In the practices i have used additional project as composition root when the dll dependencies became too complex.

About your question about how layers should resolve their dependencies. I am not sure if this is what you meant, but in DDD there is practice your BLL to define the infrastructure interfaces( like repositories) in the layer it self. This way the dependency graph is reveres. Now the infrastructure layer (DAL) you only define concrete implementation of the interfaces provided from the BLL, and again in the composition root everything is wired.

The first approach where the infrastructure layer defines the interface and the implementation has the advantage to be dependency free, which is siutable for reusage across different projects. But keep in mind when working in big domain this sometimes may lead to unmaintanable code.

The second approach being DDD the most important thing is the domain, so everything works for the domain. In my experience having well structured layers around the domain is the best option. This apporach makes your code more explicit about the problems you solve for the domain. I don't know if i have express my self corectly.

As final note i will suggest you the DDD approach if using this just as a learning experiance. Learning something new is the best option.

I am not the most experiance person in the field. I am programmer for about 3 years, and have worked mostly on middle sized projects, so my opinion is not solid ;]

Answer 2

Since I read this article I have been doing all my projects using this method. Highly recommended in understanding a "composition root" step by step.

http://www.dotnetcurry.com/aspnet-mvc/829/dependency-injection-ninject-aspnet-mvc