I am writing a design document and people on my team are willing to do the move from ASP.NET WebForm to ASP.NET MVC. This is great, but I have a hard time to understand how MVC workswith in a 3-tier (Data Layer, Business Layer and Presentation Layer) architecture. Can we say that the Model, View and Controller are part of the Presentation Layer? Is the Model part of the Business Layer?
In brief, how MVC and 3-tier architecture can work together? Thanks for the help!
I consider ASP.Net MVC to be in the presentation layer. The "Model" classes it uses are really View Models, which describe the data structures needed by your views. All of your business logic and data access should remain separate from your MVC models and controllers.
Also, the general "Best Practice" for MVC is to keep the controller code as simple as possible, which usually means introducing some for of application service into your business layer that handles the heavy lifting.
The presentation Layer is your View.
The Data Layer is your Model (recommend looking at the Repository Pattern).
The Business Layer remains what it is.
The Controller can call the business layer for functionality when the object is loaded, or the model can call the business layer for functionality when a specific ViewModel is requested, but otherwise it remains the same.
The controller shouldn't have expansive business logic in it -- put that in its own self-contained DLL.
This is pretty subjective. Do what makes sense to your team.
MVC can be pretty flexible and almost no MVC framework, across all languages, does things the same way. Even in the .net space. FubuMVC, Spring.net, and MS MVC all do things in slightly different ways.
First of all, you don't have to change to MVC just because... If you have something that is working I don't think you need to.
But to you question, the Model in the MVC pattern is any kind of class that represents your business problem, wich can be any sort of calculation, business rules or data access classes. In the MVC framework there's a folder as a way to propose a solution for you, so you can put your model classes in there, but you don't have to, you can create different projects so solve your business problems and that's your Model. So here, you can define any other patter that you for instante, you can use the Repository Pattern and implemente that using NHibernate or Entity Framework.
The Views are just web pages to show and receive information to and from the user.
And the controller is the entrance to your application, the classes that are going to receive the requests, call the necessary models and redirect to the specified view.
Hope I could helped.
N-Tier with MVC works just fine. Just follow SOLID principle and several others and you will be able to keep your application loosely coupled and cohesive.
I would say that reading the books on MVC 3 and watching pluralsight.com videos are your greatest resources. You can't go with "do what works for your team." If say work associates named Johnny and Timmy want to put a bunch of logic into a controller, just because in the short term deadline rush that "works for your team" that doesn't make it right / good / smart.
I have found so many bad articles on the internet that it is scary how many people are getting led down a dark road of misery. Follow the happy path. Use stackoverflow for opinion like art, but check with msdn articles, mvc books, and pluralsight.com
I know it's just a Wikipedia link, but there is some info here regarding n-tier vs. MVC architecture.
A "Tier" is a unit of deployment, while a "Layer" in MVC is a logical separation of responsibility within code.
© 2022 - 2024 — McMap. All rights reserved.
