MVC N-Tier Architecture I am working on a new MVC web application, so the project is in early stages. I have created 4 projects.

Let me explain what they do:

Common --&gt; contains all my DTOs, enums helpers, ViewModels etc.

Web --&gt; simple MVC application

Business --&gt; This contains providers which have an interface and implementation for dependency injection:


DAL --&gt; Contains edmx file and DB Entities


DAL is similar to Business project. It has an IUsersDAL and then UsersDAL implementation.

Do I really need the DAL classes to access the database, or can I just access them from the Business class?
Just for an example I am adding a sample code from UsersProvider.cs:
This what my BusinessProvider is doing:
    private readonly IXPTSecurity _security;
    private readonly IUsersDAL _usersDAL;

    public UsersProvider(IXPTSecurity xptSecurity, IUsersDAL usersDAL)
    {
        _security = xptSecurity;
        _usersDAL = usersDAL;
    }

    public UserSessionModel AuthenticateUser(string userName, string password, ValidationContainer validationContainer)
    {
        var userInfo = _usersDAL.GetUserByUserNamePassword(userName, _security.Encrypt(password));

        if (userInfo == null)
        {
            validationContainer.AddMessage(MessageType.Error, &quot;Login Failed. User name or password is incorrect.&quot;);
            return null;
        }

}

And then this is what is happening in the _usersDal.GetUserByUserNamePassword():
// So this is this is what UsersDAL is doing
    public User GetUserByUserNamePassword(string userName, string password)
    {
        return _managerEntities.Users.FirstOrDefault(s =&gt; s.sUserName == userName &amp;&amp; s.sPassword == password);
    }

As you can see, all I am doing in my DAL classes is a simple LINQ type read from the database. If I do this in the Providers it saves me an extra layer.
It would be nice to get someone else opinion on this before I start coding.
By the way I need a separate Common and Business because this project requires another web application and another 3,4 Windows services, which will be later added using the same Business and Common. But I am not sure on the DAL.
I personally think that what you have done here by separating the layers is better than including this all in one layer....


You're following the Single Responsibility Principle - Business Logic and data retrieval results in two different reasons for change and therefore I believe separating them in different classes is following this principle
Your IUsersDAL can be stubbed in unit testing as this is injected into UsersProvider - you can separately test data access and business logic
Reusing GetUserByUserNamePassword in numerous other business provider's means you don't have to write the same query again therefore you're promoting code reuse.  Your UsersDAL is basically a repository pattern for the entity User as this will be used for storing the numerous LINQ queries associated with data retrieval for that entity.  Maybe think object having repositories for aggregate root objects only.
What if you changed your data retrieval for a User entity from a LINQ query to accessing them from a web service - you never know what might change in your application as it grows and you wouldn't want to be directly referencing web services in your business layer, accessing them through a Repository pattern would be a cleaner way of doing it.


I think developers sometimes doubt the extra layer due to the advantages of using an ORM and Linq as like you have done as you can create the data access retrieval within one query.

ORMs like Entity Framework are Unit Of Work and Repository patterns in themselves this is why having an extra layer to contain the query seems to be trivial, however I believe you're merely extending the repository as you're encapsulating data retrieval logic specific for an entity.