Note that there are some explanatory texts on larger screens.

plurals
  1. PO
    text
    copied!<p>One solution would be to use MVC as a Presentation layer (as you are doing it right now). Inside of your MVC there will be cases when a model would not be sufficient for you in which case you will need to create ViewModels. You can move the ViewModel to the business layer in which case when BLL retrieves data from DAL, it converts it into some ViewModel with some functionalities and defaults, and send it over to the presentation layer. Once the presentation layer finishes with using the VMs, it passes the data to the BLL which can perform some special validation and some extra business logic. After that it would create model(s) by extracting data from VM and pass it to DAL which can perform transactional update, delete or insert.</p> <p>Normally my solution at minimum has five projects. I have API project, MVC, Business Layer, Data access layer and Resources.</p> <h3>API</h3> <p>This project contains models, interfaces, abstract classes, etc. In essence it contains everything that other layers need to implement. There is usually IRepository for the Repository Pattern implementation, IUnitOfWork for the Unit of Work pattern, models which are either generated by Entity Framework or by hand (but no mappings). ViewModels are also here together with extension methods for converting to and from the models.</p> <h3>Business Service Layer</h3> <p>This layer is in charge of fetching the data from the data access layer, converting it to the view model by invoking extension methods, initializing values. Also, if a DAL returns null value, the business service layer will not pass it over to the presentation layer as null, but will return an implementation of the Null Object Pattern. The Null Object Pattern is actually implemented in API and is called by business service layer. This layer references API layer.</p> <h3>Data Access Layer</h3> <p>Here you normally implement the repository and unit of work patterns. Instead of directly communicating with EF, you would wrap calls to DbContext into these two implementations. In addition to this, mappings from models to SQL Server tables and columns, as well as foreign keys are done here. This layer references API layer.</p> <h3>Resources</h3> <p>All the resources, strings, language translations, etc are located here. This project does not reference API, but Business Service Layer, Data Access Layer and Presentation Layer reference this project to get access to the strings.</p> <h3>Presentation layer</h3> <p>This is normally an MVC solution (or if it is Web Forms then there it will be implemented using MVP patter). This solution communicates with Business Service Layer. It receives ViewModels and return values from the business layer. It passes the view models if they are valid to the business layer in order to have them persisted.</p> <h3>Linking layers</h3> <p>The layers are connected among themselves using dependency injection. I usually use Unity and configure my application using external configuration settings. This way the Presentation layer, business service layer and data access layer do not have explicit reference. MVC does not hold a direct reference to BLL, BLL does not have a direct reference to DAL. The constructors for controllers and BLL and DAL classes use interfaces and unity passes the appropriate implementation.</p>
 

Querying!

 
Guidance

SQuiL has stopped working due to an internal error.

If you are curious you may find further information in the browser console, which is accessible through the devtools (F12).

Reload