I will begin this question by admitting I am very new to MVC. The design pattern makes sense to me at a high level, but now that I'm exploring ASP.NET MVC, some of the architectural pieces are challenging my preconceived notions. Learning is a good thing.
I've been working with Oxite lately as a learning tool written by people at the company that created ASP.NET MVC and thus, an ostensible reference application for ASP.NET MVC.
But today I saw a blog post about Oxite by Rob Conery that says:
One of the things that the Oxite team
decided to do was to separate the
Controllers and Views into another
Project for what I can only assume is
the separation of business logic from
view logic. This can lead to some
confusion since Controllers are meant
to handle application flow - not
necessarily business logic.
This has thrown me for a loop. Is this separation a tenet of MVC and thus a mistake by the Oxite developers, or is it Rob's opinion? If the business logic belongs in the model, why did the Oxite team put it in the controller? How do I execute an action that is business logic if not in the controller?
Further to that, am I making a mistake using Oxite as a learning benchmark considering comments like Rob's?
Your business logic goes in your business layer. The controllers use the business layer to create a model for your views to render. A good example is the MVC Storefront application that Rob Conery has produced. Oxite is currently getting lots of bad press as it apparently does not make good use of the MVC framework.
The reason that you want a business layer that is separate from your controllers is you may want to reuse the business layer across multiple controllers, or even multiple applications. An example of this would be normal user functions for displaying data, and administrative function for updating and adding data. You may make use of the same BL components in both cases but have different controllers and views to render to the data. Model objects would be the same.
You could implement your business layer (i.e. the Model) with your entities, aggregates, repositories, and services. The services call the repositories, which pull data from your DAL in the form of entities.
This can be set in a single, seperate project which is nothing more than a DLL.
Next, have your MVC App, which is really your Presentation layer, and have it utilize your business layer project. the controllers will work with your Services, and pump the data those Services generate into ViewData which is then pumped into your Views.
The controllers should only deal with routing concerns, such as which views to display, based upon user input from forms, querystrings, cookies, sessions, etc.
there has been an uproar from the "MVC purists" community about the validity of Oxite being used an a good MVC example. The bottom line is, business logic should not be contained in controllers, which I am sure you will see as Oxite gets refactored over the coming months.
Related
I keep reading that the biggest layer in the MVC pattern should be the model. I've also heard that we should avoid putting logic on the controller layer. However, as my ASP.Net MVC 5 application is getting larger, I see that I'm getting heavy views, heavy controllers, and... extremely tiny models (they're not more than references to my SQL tables).
Yes, I admit, I could never manage to put any logic on my model.
I like the MVC pattern, and my website is working good, but I keep on thinking that I'm surely not doing things right...
Can you show me some useful links about how to write MVC code properly? Rick Anderson's (Microsoft) MVC 5 tutorial is fine, but once again, his models are indeed very tiny...
In my applications I put as much logic as possible in the domain models. On top of that there is an application layer which interacts with the database and domain models to perform application specific operations. The controller actions have as little code as possible and just call methods in the application layer.
In addition I usually have a view model for each view. Any logic that you have making your views "heavy" would go there.
One of the main reasons I try to put as much logic as possible in the domain models is to make unit testing easier. Logic in the application layer usually involves the database, which you will need to mock in order to test. Moving logic to the domain models makes testing easier and makes you code more reusable.
This is a pretty complex issue. I have an in depth blog post on the question if you're interested.
This answer is also pretty close to what I would suggest.
You're missing a service/business layer which should be injected in your controllers though "Dependency Injection". These services do all the heavy lifting.
Having Models without any methods or operations in them is a good thing. You're only storing this info anyway. They basically just get; set; data.
Use extra layer between models and controllers (for example repositories as data access layer).
I strongly recommend using ViewModels-they make code much more organized.
You should Create Some Classes that purely doing business logic and emit ViewModels for MVC view. Controller should respond to actions and the action method delegate the responsibility of getting the model to this business classes.
After some research on this issue, and taking into account some of these answers and comments, I realized that a medium sized MVC project can't rely exclusively on the 3 layered model. As the controller actions become bigger, the developer starts feeling the need of creating a 4th layer: the service layer. Like Gunnar Peipman correctly suggests in the following blog post, "Controller communicates with service layer and gets information about how access code claiming succeeded": http://weblogs.asp.net/gunnarpeipman/archive/2011/06/20/asp-net-mvc-moving-code-from-controller-action-to-service-layer.aspx
I know this has been sort of answered in various posts, but using VS2012 with MVC4, I wonder if there is a more updated method or new ways to do things.
I have a large enterprise application that has 22 projects in it. It has a complex large business object/logic project and has multiple presentation layers. Working on a new presentation layer using MVC 4. I have never used MVC before at this scale.
Here are my questions:
How do people handle the model in this scenario? All the Microsoft examples are so simple.
I have seen posts to auto mappers and recommend deves use simple models and extract from the BO layer, but some of these tools like auto mapper seem to have gone idle, is there a library in MVC that does that now?
I'm just trying to figure out best practices before I get started, seems usually I figure them out after the fact.
I break my MVC apps into several different projects.
AppName.Configuration: to handle any configuration of the app (i.e. pulling in web.config/app settings, etc)
AppName.Data: this is the data layer where all DB access is performed (no business logic). The DBML/EDMX lives here, my repository class(es) live here as well.
AppName.Models: this is where all of my ViewModels are defined for MVC, as well as other model objects needed throughout the application.
AppName.Services: This is my business layer, all everything must pass through here to get to the data layer or to the presentation layer. ViewModels are constructed from the database objects, data validation happens here, etc.
AppName.Web: this would be the MVC application.
AppName.Data.Test: Unit tests for Data app
AppName.Services.Test: Unit tests for the services
AppName.Web.Test: Unit tests for the MVC controllers
AppName.Web.UI.Test: Unit tests for the web user interfaces (using WATIN)
I don't use any auto-mappers, as i clearly define a specific viewmodel for each view of the application. If it isn't needed for the view, it doesn't go in there.
Most MVC examples are so basic, they show everything in the web app (data, models, business logic in the controllers, etc.)
I hope this helps.
ASP.NET also has UI, Event Handling and if good logic layer is implemented then the BLogic layer too. So that can we say its Model View Control style. Or its not that ?
No. ASP.NET Web Forms is an implementation of Page Controller pattern.
Chapter of Fowler's PoEAA about the Page Controller on Google Books
As a pattern MVC is more concerned with the idea that the controller orachastrates the view and the model.
In Web Forms there is no controller. The View and the code behind (closest thing to a controller) are inherently the same thing, there is no separation of concerns.
Also depending on how you go about it, the model part of the MVC isn't necessarily your business logic. For us its literally a View Model, and contains data relevant to the specific view only. Business logic is handled in autonomous components.
With traditional web forms, I generally see the code behind (which is really part of the UI) having intimate knowledge of either business logic or data base access (and often a mixture of both).
Due to code behind it is hard to get away from this.
In my mind web forms create tightly coupled UI and business logic, and don't provide an easy way to enforce separation of concerns.
I'd say web forms does not adhere to the MVC pattern.
In MVC, all requests are routed to a Controller.
In ASP.NET all requests are routed to a Page. That is a View and not Controller.
ASP.NET better matches with MVP rather than MVC. Reason being, in MVP, a View is supposed to process user inputs/requests and pass it on to appropriate Presenters.
We have started using MVC framework and now we are bit confused where to write business-logic, in controllers or models?
For the project we are going to use WCF layer as DAL.
People have different views on Model & Controller, and think differently of writing business logic either in 'M' or 'C'.
What is the best practice?
I believe we will be accessing WCF (DAL) service in Model and applying all the business logic or filtering and then Controller accessing the data from Model.
These are my rules:
Controller
Mainly Pageflow . Determines what View is displayed next.
Has access to Services ( ie productService.GetProduct(Model.ProductID) )
Model
I have 2 of them.
POCO-Classes - used by all layers (BLL,DAL)
ViewModel - used by View and Controller for stronly typed views.
View
Hopefully mainly easy HTML
I try to have the layout in a way, that it is possible to have different kind of people work at the project: The frontend guy and the backend guy.
The backend guy will do the Service and Repository.
The Frontend guy will do Controller and Views. He also does ajax.
Try to keep -Business- logic and -Application flow- logic separate. Most people tend to mix those together as -business logic-
Most people keep their business logic in the model and this is considered best practice. Steve Sanderson who has written xVal endorses this method.
As I’ve discussed before, validation rules should go in your domain model, because the role of your model is to represent the workings of your business. It ensures that the rules will be enforced consistently, regardless of whether the UI coder remembers them or not.
Check out his post about xVal that talks about the problem you are discussing.
Do not think that model is supposed to be build from data access logic (wcf service in your case) only. I would recommend you to check out Domain Driven Design, it goes well with MVC. Controllers shouldn't contain any business logic. Controller action method should be ~20 or less lines. But that's just my opinion (made up from countless sources).
Greetings,
Apologies in advance that I have not researched this toughly enough to answer the question myself, but I imagine it would take me some time and I would rather know now before I invest more time in learning it. I couldn't find anything in my initial research..
Why use ASP.Net MVC if your already using a multi-tier architecture (Data Layer, Logic Layer, Presentation Layer)? Other than the fact the controller has more power than the logic layer.
Am I right in thinking I can use nHibernate and all my data access classes, entities, and mappings in the Model part of the MVC?
When using controllers, is it best to separate a lot of the logic into a separate class so I can call it from multiple controllers? Or can I call them from the controllers themselves, considering the fact that I would not want all of them to be Actions, just normal methods.
Thanks
MVC is not to replace N-Tier, it is a way to organize the presentation layer.
I would not say that the controller is more powerful than the logic layer. Instead, the controller (as a part of the presentation layer) should still call the logic layer.
Controllers should only prepare data for views and handle actions from views. You should still use your BLL.
Yes, NHibernate entities can (and they should be) be passed to the views.
This will you get you into some trouble. You should use flattened, null-safe DTOs a.k.a. view models.
Damien, you might want to read these 2 posts:
The Fat Controller
An Architectural View of the ASP.NET MVC Framework
N-tier is an archtitectual pattern, to enable reuse, seperaation of concerns and scalability of the key areas of your application.
The non UI layers (Business, Data, Facade etc.) should be unit tested and UI agnostic.
The UI layer is just one of these layers weather it be Silverlight, ASP.NET MVC, web forms etc.
MVC, like MVP is a design pattern that enables better testability of the UI Layer.
ASP.Net MVC is an out of the box framework that supports and enforces this pattern.
The pattern was arround an in use long before this framework.
But this is simply a UI layer choice, There should be no interaction with databases, services etc in the controllers, they control the state of the view using the model, Should not control the business logic, peresistence, transactions etc.
To answer your question on why use if you are already going multi-tier is that it makes for more organized and search-engine friendly URL's. Also, it is more of a standard pattern than the other patterns tend to be in ASP.Net. That makes it more developer friendly for those that are already using MVC on other platforms.