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.
Related
I'm new to MVP .
can I use tutorials created for asp.net MVC to learn MVP pattern foundations and basics?
or differences are too much ?
The 2 patterns are pretty different. The MVP pattern could be used with classic WebForms whereas ASP.NET MVC already integrates lots of the MVC pattern's parts in the framework itself. The separation of concerns is already present. If you want to use MVP with classic WebForms you will have much more work because the pattern is non-existent in the framework.
MVC is good for plain server side scripting. In MVC developers always try to keep the controller very lean. Mainly controller is for just selecting the appropriate model and reflect on the view. But in today's web applications the View part has radically changed and became complex enough to produce a big, fat and messy controller. So now we need a new place to put the user interface's complex control logic. Here the P of MVP comes in that is the presenter. So presenters are responsible for controlling the logic for a particular user interface component. Don't worry the controller is still here, named as Application Controller. Which ultimately responsible for switching between comparatively larger application components. So MVP can also be said MVPC(!!). BTW this was my way of understanding MVP and obviously not any ground rule. But Google has some very cool documentations on MVP.
I'm trying to understand a 3-layer design where MVC is (or is in) the Presentation Layer. Specifically, how would the top-down interaction concept work with respect to the Business Layer, a ViewModelBuilder, and the MVC Controller.
Should the Controller itself access the BLL?
Where does the ViewModelBuilder fit in to this?
I'm just starting to understand that the Model in MVC is actually the ViewModel rather than the Business or Persistence Model. Am I way off here?
Your confused because of the countless examples online that don't make any distinction between a simple MVC architecture and one that is serving as only the UI layer in a larger enterprise architecture. Most likely, you need the latter.
In an application of any level of real sophistication, yes, you'll want to think of your model classes as view models and then map them back to your domain model. Check out Automapper to help automate this.
Here's two really good articles that were helpful to me that I think are really well written:
http://blogs.msdn.com/b/simonince/archive/2010/01/26/view-models-in-asp-net-mvc.aspx
http://blogs.msdn.com/b/simonince/archive/2010/12/07/view-model-versus-domain-entity-validation-with-mvc.aspx
Moving from the traditional way of architecting web applications with a Business Layer, Service Layer, Data Access Layer and a Presentation Layer to the MVC design pattern, I find it difficult to understand how it fits in the old model.
It seems to be that the MVC model itself already has done allot of the separation of concerns that is needed and used to be achieved via a layered architecture. Can someone shed some light on this subject please?
As a reference, below is how I understand it, please share your view on this
MVC Views and Controllers along with View Models -are- Presentation Layer
MVC Models - could be - Data Access Layer or Business Layer or even Service Layer
I see the Asp.Net MVC part only as the view (or presentation) part of the whole application.
I struggled too with the problem how to structure the app in a proper way.
Following the Onion Architecture I heard about here (and especially the image found here), my solution looks this way:
Project.Core
Business logic/services implementations, entities, interfaces that must be implemented by the other projects (i.e. "IRepository", "IAuthenticationService",...)
Project.Data
DB connection - in my case NHibernate repositories and entity-mappings go here.
Implements data-interfaces of Project.Core
Project.UI.Web
The Asp.Net MVC ("presentation") project - it wires the whole app together.
Has implementations for Interfaces in Project.Core and wires them (and those from Project.Data) up with some DI framework like Castle Windsor.
Project.UI.Web follows the following conventions:
its models are only(!) viewmodels
the views consume their own viewmodel (one-view-one-viewmodel)
the controllers just need to validate the input, transforms it into domain objects (as the business logic knows exacly nothing about viewmodels) and delegate the real work (business logic) to the business services.
Summary:
If you follow this model it's helpful to focus on Project.Core: that is the real application. It doesn't worry about the real persistence of data nor cares about how does it get presented. It's just about "how-to-do-it". But it's laying out the rules and contracts (interfaces) the other projects must provide implementations for.
I hope this helps you with how to layout an Asp.Net MVC application!
Lg
warappa
As others have said, it doesn't change much. My apps are typically architected as such:
Model Layer (Domain and View Models)
Repository Layer (data access)
Service Layer (sometimes implemented
as WCF services depending on the
app/requirements)
Server side MVC
Layer (Asp.net MVC itself)
Client side MVVM or MVC (via
either Knockout.js, Backbone.js, or
Spine.js)
In the server side MVC layer, my controller methods are very light. They typically call a method on a service layer object to get some data and pass it along to the client as Json data.
Because I'm sending Json back, my views are also very light and sparse. Typically just containing script includes and templates which will be rendered with a client side templating library.
In short: nothing much changes.
I'm only familiar with a few presentation patterns: MVP (Model, View, Presenter, common in windows forms/asp.net), MVC (Model, View, Controller) and MVVM (Model, View, View Model, commonly used in WPF/Silverlight).
Link: http://haacked.com/archive/2008/06/16/everything-you-wanted-to-know-about-mvc-and-mvp-but.aspx
Above link should answer some (if not all) of your questions.
The way I usually write ASP.NET MVC applications is by including at least a Service/Business layer hybrid for CRUD operations (because data access belongs neither on the view model or controller and definitely not in the view!).
Very basic explanation:
If you create a new MVC application you will automatically get a Controllers, Models and Views folder.
Your controllers act like your Business Layer
Models are Data Access/Service layer
and Views are the presentation layer.
See http://www.asp.net/mvc for a fully detailed explanation.
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.
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.