I am using Visual Studio 2013 MVC 5 application using Razor.
I want to understand in which order layers sit and interact with each other.
In my solution I have:
- UI Layer (Main Project) – comprising of Model, View and Controller
- Data Access Layer (Class Library) – which contains generic Stored Procedure methods and Connection Class
- Repository (Class Library) – which contains data access code (Create/Update/Delete)
- Business Layer (Class Library) – which contains business validations
- Separate Layer for REST
I am preparing architecture diagram and want to understand how layers talk to each other.
I assume the order is like this:
**Data Access Layer -> Model -> Repository -> Business Layer -> Controller -> View**
Where does REST sits?
I assume by REST you mean a Web Api of some sort?
this should be an alternative UI layer ie
DAL -> Repo -> Model/Services
-> MVC app
OR
-> Web.API
OR
-> Windows app
OR
–> Mobile App
etc
Alternatively you can expose the repository as an API layer (although you’ll have to consider security)
DAL -> Repo -> RepoService API -> RepoClient -> Models/BLL(ie on a mobile app with web data)
AND/OR you if your Business logic is comprised of services you can expose these
the idea is to rewrite as little code as possible when you change the user interface
First MVC has 3 layers. Model, View, and Controller. Trying to Make BLL or n-Teir Layers fit is not going to work very well.
M – Model, this is where you “access and store” your data.
V – View, This is where you render, or represent your data.
C – Controller, This is the glue that lets views tell your models how/what to render via views.
In a modern web application, there are actually several applications at work.
Your DAL could probably be an MVC application, Models being tables, Views being the output of the stored procedures and Controllers being the stored procedures themselves.
“Repository” could be a MVC application where the model is the class objects that store data after retrieval from the DAL app. The controller would be what ever logic you have to select what needs pulling from the DAL. And the view would be, for example an exposed webservice.
And so on…
Basically, It would look like your project (or your understanding) is not using MVC properly. MVC is not always the best tool. Sometimes good old n-teir is “better”.
A good example of an multi-MVC application:
A Web service that feeds a Mobile App and a Javascript/HTML app.
The web service would have it’s own MVC, Models consisting of database/storage access. Views being the rendered web service json/xml. Controllers being authentication logic, and server side validations.
The Mobile app would be a MVC app, the Models being the classes that retrieve data from the web service. The controllers being classes that help translate the web service data to the views. And the views being the XML (android) or nib (iOS) files that get rendered.
The JS/HTML app would be the same structure as the mobile app. The Models being the part that gets/and holds data from the web services. The Controllers being the classes that “parse” that data, and the views being what ever is rendering the HTML.
The main problem with trying to get n-teir to fit in MVC terms are that they are not comparable, exactly. Your Business logic should be in two places. Either controller (if controlling things) or models if validating things. DAO fits in controllers (select * where x=1) and models (CRUD). Views and UI are pretty much the same. But UI/BLL/DAO is not the same as MVC. You should try to pick one methodology and use that instead of trying to blend the two.
Also, just to make sure were talking the same thing UI can’t be a whole project. I assume you have a UI project which could be an MVC app with the models pulling from the DAO project.
1