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.
Related
I have to set up a Asp.net demo using MVC 4 in a web application in order to help decision for a product that currently don't use this pattern. The model, view and controller should be simple, I just have two or three entities and a few pages.
I suppose I don't have to implement the whole infrastructure with services, repositories, etc. So how could I simplify the MVC components without loosing those advantages?
The MVC components aren't related to the data access strategy which you can use. To put together a quick demo (or a simple application) you can leave the data access in the same project but eventually split that out etc.
You can use something like AutoMapper to map from your entities to your view models if you want to put that level of abstraction in. You can also use EntityFramework contexts in the controllers to avoid additional levels of abstraction and only put in a simple interface/abstraction into one controller to show unit test ability.
Small examples of different patterns which could be used in the application is probably the way to go for the demo/presentation and not worry too much about putting them in all over the place. Remember the presentation and the delivery of information is as important, it not more, than the demo code itself.
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.
The more I read into Asp.Net MVC the more layers and components I find out are required in order to make my application follow all of the standards and best programming practices.
It's starting to get a bit confusing because some of the new layers don't seem to fit in as easily as the others I learnt. So I just wanted someone to go over all of the required/recommended layers for an Asp.Net MVC application- what purpose they serve and how they interact with the other layers.
Here's a few of the layers I've found and how they link up:
(Some of them may be wrong)
View/UI --> Model Binder --> Controller --> Service Layer --> Repository --> Entity Framework/LINQ to SQL --> DB
Could someone go over ones I may be missing, how they all link up, and what each of their purposes are?
Thanks,
Matt
Good question, I think you covered all the layers I have seen: Modal binder and service layer are optional.
Maybe, you can add another Error Handling layer such as elmah.
View/UI --> You put your html markup / Javascript code.
Model Binder --> You perform the magic to bind your input to the action parameters, normally, you will use the default binder, so you don't need worry about it. However, you can override this with your own binder, and do validation in this layer. Here is a good example on this.
Controller --> Enough documentation online.
Service Layer --> A lot of people do validation and other business logic processing here before sending it to repository. Asp.net mvc contact manger example has a good example here. This is also the layer to actually work with your modal.
Repository --> Simple read/write operation.
Entity Framework/LINQ to SQL --> DB - Actually writing to database. Nhibernate is another good candidate here.
First of all, I think software and patterns have a tendency to overcomplicate things. As the ASP name implies the main idea of the framework is Model-View-Controller (MVC). You could be able to put a lot of things between these components, including DBs, Services, APIs, etc. However, the main concept of the Model-View-Controller pattern is pretty simple: Separate those functionalities into modules so the project could be easier to mantain.
MVC could be applied to ANY programming or scripting you do. Even for a shell script MVC could be helpfull. Here are some examples of each one:
View - Here is how the user interacts. It could be a web page, and Windows Form, or a command line interface.
Controller - The brains of the program, it should be aware of everything, but should be pretty simple. It basically gets messages or events from the view and/or model and decides on what to do. Good controllers are basically a dispatcher of events. Depending on events, it call view or model methods. In ASP MVC, the controller is the one providing the ActionResults for the View and interacts with the Model.
Model - This is basically where the data is. This could be a DB, file system, a Web Session, or memory.
Now the good part. The Controller does not care how the View is managing the interaction with the user. It could be a command line interface or a web form. The Controller does not know how the data is stored, it does not matters if it is a DB or a file. It just request data and pass it to the View. It not of its business to know how the view is getting the inputs, or the model the data.
Then the question, Why the hell do we want to overcomplicate things with this pattern? Well, Imagine that you have an MVC application using a MySQL DB and know you want to use SQL Server. What module you should change? Obviously the Model is the one affected. The Controller and the View should not have any major impacts. Now, imagine that you have another MVC application using Windows Forms, and now you want to change it to Web Forms? Well basically the View is the one that will be affected (and some parts of the controller), but your Model should be the same.
In summary, MVC is a great pattern, and it should be used more. However, I think there are some projects which are not suitable for MVC due its simplicity. It will be like building a laser to kill flies. Of course you will kill them, but the effort is not worthy on all cases.
My opinion is it does and it doesn't.
It does separate logic and data from UI, but it still crams it all together into a single point application.
That's why I think it doesn't really, because Controllers are business logic, Views are UI, Models are DAL. These are now just layers within the same app.
But are layers supposed to be the first or the second variety to be actually called layers?
Anyone wants to add their own 2 cents?
The MVC template project is just to get you started - you can easily move the Controllers and/or Models out to separate projects if you want to, and if it makes sense in your application. Remember, that for a small app with maybe three controllers, a couple of extra classes in the Models layer plus an EF or LINQ data model, you really don't have enough files to justify separation into different projects.
I don't think of Controllers as business logic. They are application logic, the glue which ties together the business logic (Model) and the presentation logic (View).
Well, my birthday cake had layers but it was still one big cake... so yes?
Off course it does!
I think both views and controllers contain user interface logic... the business logic should be in the model (which is not only the DAL).
As the model you could use e.g. CSLA objects and add another couple of physical layers as needed (through configuration).
You have to know there's a difference between logical and physical layers (or layers vs tiers)...
There are a lot of interesting articles on lhotka's site regarding this topic!
E.g. this one and this one.
Layers and tiers are interchangeable. In context of an n-tier you'd call it a presentation tier but in context of a layered application you'd call it a presentation layer. But really they are the same thing.
A litmus test of n-tier application and loose coupling would be if you can take each of the tiers and build them as separate projects and deploy them on different machines.
The key differentiator for n-tier applications is Separation of Concerns (SoC) and low coupling. A truly decoupled application might be one where you have a tier that contains nothing but pure HTML. Then another which contains pure Javascript and uses AJAX to update the DOM and communicate with the web service. The web service comprises it's own set of tiers.
The web service has a routing engine that routes the requests to the different controllers. The controllers sanitize and interpret the request, verify authentication and what not and call the appropriate models. the models in turn must return POCO objects or DTOs and return these to the Javascript which injects them into the DOM. The Javascript may modify the objects and send them back to be persisted into the database. Entity Framework 4.0 has good support for just such n-tier scenarios though it does fall a bit short in the SoC department (strongly types views for example) but it's practical for more purposes.
MVC Futures I believe has support for some Inversion of Control (IoC) containers out of the box and currently if you want loose coupling and truly n-tier scenarios you will probably need to use an IoC container of your choosing.
"Tier" usually refers to different physical servers, while "layers" refers to separation of functionality into loosely coupled areas.
That is, a 3-tier web application:
Tier 1) DB Server
Tier 2) Web Server
Tier 3) Client browser
3-layer web application:
Layer 1) UI
Layer 2) Business Logic
Layer 3) Data Access
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.