I've been using ASP.net MVC for about two years now and I'm still learning the best way to structure an application.
I wanted to throw out these ideas that I've gathered and see if they are "acceptable" ways in the community to design MVC applications.
Here is my basic layout:
DataAccess Project - Contains all repository classes, LINQ-to-SQL data contexts, Filters, and custom business objects for non-MS SQL db repositories (that LINQ-to-SQL doesn't create). The repositories typically only have basic CRUD for the object they're managing.
Service Project - Contains service classes that perform business logic. They take orders from the Controllers and tell the repositories what to do.
UI Project - Contains view models and some wrappers around things like the ConfigurationManager (for unit testing).
Main MVC Project - Contains controllers and views, along with javascript and css.
Does this seem like a good way to structure ASP.NET MVC 2 applications? Any other ideas or suggestions?
Are view models used for all output to views and input from views?
I'm leaning down the path of making view models for each business object that needs to display data in the view and making them basic classes with a bunch of properties that are all strings. This makes dealing with the views pretty easy. The service layer then needs to manage mapping properties from the view model to the business object. This is a source of some of my confusion because most of the examples I've seen on MVC/MVC2 do not use a view model unless you need something like a combo box.
If you use MVC 2's new model validation, would you then validate the viewmodel object and not have to worry about putting the validation attributes on the business objects?
How do you unit test this type of validation or should I not unit test that validation messages are returned?
Thanks!
Interesting.
One thing I do differently is that I split off my DataAccess project from my Domain project. The domain project still contains all the interfaces for my repositories but my DataAccess project contains all the concrete implementations of them.
You don't want stuff like DataContext leaking into your domain project. Following the onion architecture your domain shouldn't have any dependencies on external infrastructure... I would consider DataAccess to have that because it's directly tied to a database.
Splitting them off means that my domain doesn't have a dependency on any ORM or database, so I can swap them out easily if need be.
Cheers,
Charles
Ps. What does your project dependency look like? I've been wondering where to put my ViewModels. Maybe a separate UI project is a good idea, but I'm not entirely sure how that would work. How do they flow through the different project tiers of your application?
Related
I'm trying to learn dependency injection. The book/example I am following seems to be using an MVC project as just the UI layer within a broader architecture. The example includes a separate project for the domain layer and yet another project for the data access layer.
When I first learned MVC I came away thinking MVC was the entire architecture. V for view for UI layer, C for controller for domain layer, and M for model for data access layer.
So is using an MVC project as only the UI layer a proper and/or commonly accepted application of the MVC framework?
So is using an MVC project as only the UI layer a proper and/or commonly accepted application of the MVC framework?
Yes.
While it is possible to make an application entirely within the context of ASP.NET MVC, doing so means that the application will have to be written from scratch to use a different UI framework. Isolating the business logic into a separate set of services that are not coupled to ASP.NET MVC means that only the top layer would need to be replaced to move to a different UI framework, which also means that the application's lifecycle may extend beyond the end of ASP.NET MVC and/or it can be made into an application with a different UI framework (WebApi, WPF, etc) without too much trouble.
The purpose of dependency injection is to decouple your services from all other parts of the application, including each other. So by extension, it is only natural to build the business layer separately from the UI layer. Whether you physically have them in one assembly or multiple is really just a matter of preference.
Applying SRP to the MVC design pattern will lead you there. Same goes for MVVM. You are extracting logic from Model to other classes like Interactors, Services, Repositories etc.
From any point of view this is perfectly normal(and desirable). Your Model is just an abstraction of Several different layers.
I would suggest you to take a look at VIPER (not a car) - https://www.objc.io/issues/13-architecture/viper/ and you will see something that is occuring to you right now.
I have been jumping between articles and questions but i can't seem to find the information i want.
When i started learning about MVC, tutorials and articles pointed out that:
*Models: is where you business logic goes
*Controller: is where data-access and handling request/respond happens.
I have been working with MVC for a while now and I wanted to migrate an old simple project to MVC. In the project i have a business and data access layers.
After reading about N-Tier MVC architecture, my understanding changed.
The model in which i usually presumed to be the business domain has now changed to be more of a presentation depending on views. Its true that models reflects the business entities but it acts as another layer over it.
So my question here is the following: Assume that i have an MVC project and i have another two projects, business and data-access. Is the relation in this manner right ?
*A model, will mostly have the same properties as in its corresponding business entity.
*The controller will call the DataAccess-Layer to retrieve data, the data will be returned as business object which will be mapped into a model and then returned into a view.
Model not always corresponds to business entities. Because models in MVC used to reflect entities that will be sent to view. So they may be little bit sipmlier than domain business entities. It is correct that your domain model will be mapped to mvc model.
Second statement I agree 100%.
Is the relation in this manner right ?
My answer is that depends on your project scale and team size, But let me explain you my projects architecture.
MVC: A presentation layer, It is the startup project of the application.
Common: This is a class library which contains a set of core classes, such as helpers, base classes, ... This project is referenced to all other projects.
Repositories: For reading from and writing to a database, I've created a project and named it repositories. This project is a combination of repository and the Unit of Work pattern. Implementing these patterns can help insulate your application from changes in the data store.
Test: Unit tests are written in this project.
Hope this will help you.
I have been reading countless articles about how to architect a new MVC 3 application using best practices.
90% of the articles combine the EF EDMX files into the same project as the MVC app. Those that do seperate these items into their own projects don't clarify which project each goes into and what references each project has. Usually they consist of code snippets that are great to teach how to do a specific function, but don't tell me how to architect the solution.
I believe that I need at least 5 projects in my solution. Can anyone tell me if I have the correct layout here?
Data Access Layer - Contains the EF EDMX files. (Perhaps the DBContext auto-generated code?)
Business Layer - Contains the IRepository and Repository classes, UoW classes, as well as the business logic for the domain. - Contains reference to DAL.
ViewModels - Contains the viewmodels that will use AutoMapper to go between my DAL and the presentation layer. - Contains reference to DAL.
MVC 3 App - Standard MVC 3 app. Contains references to the BusinessLayer and the ViewModels projects.
Test - Unit testing.
Does this look right? Can anyone point me to a good article that uses n-tiered development with ViewModels, AutoMapper, Repository patterns and EF4?
When looking at what project to put something in, it helps to think about how you are going to be deploying your code. Put code that will ship together in the same project and then use namespaces to separate it out logically into separate tiers. For most of the projects I work on it tends to be pretty simple with 3 projects.
Business Layer
Domain/Business Model and Services
Data Access Layer
MVC App
View Models
Automapper
Controllers
Views
Tests
Unit tests
I like the following
Domain - contains models and ViewModels
Services -business logic and viewmodel hydrating (ie population) code
Contracts or interfaces - repository interfaces, unit of work, IContext, and ICache
Web site
DataAccess - concrete implementation of entity framework
Some include their AutoMap code directly as an action filter as an attribute inside the web project. My automap code is done in the services project (but again this is up to you) unless I can use the attribute to do it in the controller.
btw see Jimmy's nice attribute here:
http://lostechies.com/jimmybogard/2009/06/30/how-we-do-mvc-view-models/
What you have outlined above is fine as well though. This is a very subjective matter. My general recommendations are that 'if someone can open a project and have an idea where to look for something, you are likely doing it correctly'
The way I usually do it:
Model project - Contains the model generated from the db and the context.
POCOs project - Contains the Business entities
Controller project - similar to your repository
MVC3 project - front end, INCLUDING view models and repository classes that include automapper equivalencies.
Unit tests
Architecture is technology independant, whether you are using EF, Hibernate, MVC, webforms etc... And you usually combine patterns. Besides is mostly depends on each particular project.
Regarding to best practices, when talking about EF, I can't link you to the source I use because I use a book. However I'll link you to the author's blog, it's Julie Lerman's Programming Entity Framework.
I'm trying to architect my MVC web project and I'm running into a bit of a problem.
I am using EF4.1. I've created a DataAccess project with the EDMX file. Then I use the dbContext generator to make my POCO .tt classes.
As it is right now, my Business logic layer can access the POCO classes just fine, but the presentation layer cannot.
I think that I'm supposed to create another level of abstraction and put the dbContext .tt files into their own project so that both the BusinessLogic layer and the Presentation layer can access the POCO classes, but only the BusinessLogic has access to the entity framework. The presentation layer shouldn't need to know anything about EF.
Something like this...
POCO Classes - DataAccess
| |
|---------Business Logic
| |
|_________Presentation
Am I on the right track here, and if so, do I simply cut/paste the .tt files into the new project or is there a way to force the dbContext add-on to create these in my other project?
Your presentation layer doesn't have to know anything about the EF. Just reference that project from your presentation layer to access the models.
However - your presentation layer shouldn't ideally be using any of those POCO models. They should be using ViewModels. I dont necessarily believe in the DTOs here as DTOs have a specific purpose. Your repository/data access can return models but generally those get returned to a service layer. The service layer then would return your ViewModel representation to your controller.
This sets you up nicely for dependency injection as well, since into your controller you just inject your service layer. Into your service you can inject then any repositories you need, and so on.
Ironically I think I may be working on a book for this exact subject shortly : )
Consider sending Data Transfer Objects between your Business Logic and Presentation layers. This would allow you to shape the data for your views and and prevent information from leaking into the Presentation layer (e.g. if you have a field in your POCO that is needed for your business logic but doesn't need to be available in your Presentation layer).
The question is, how would you move data to and from the
presentation layer? Put another way, should the presentation layer
hold a reference to the domain model assembly? (In an Entity Framework
scenario, the domain model assembly is just the DLL created out of the
EDMX file.)
From a pure design perspective, DTOs are a solution really close to
perfection. DTOs help to further decouple presentation from the
service layer and the domain model. When DTOs are used, the
presentation layer and the service layer share data contracts rather
than classes.
A layer of DTOs isolates the domain model from the presentation,
resulting in both loose coupling and optimized data transfer.
If you go this route, also check out Automapper to help with mapping your DTOs to POCOs and vice-versa.
So there are several ways to structure your project. What you are referring to is one way, in which you share poco's between all layers.
Another way is to have your POCO's be in the data and business layer, then create a similar object model that's shared between UI and business layer. Finally, you might also create a third model for the UI only called teh ViewModel.
It all really depends on your needs. If your object model is very complex, then you might need to simplify it with ViewModels.
I am using MVC3 for my application and I have a question about validation. I have a Business Logic layer that is separate from my web layer where I will have a function like CreateUser, which creates a new user for the application to use. I want this function to be accessible in two places: 1) Somewhere in a controller that makes use of it and 2) in a "Setup Data" program that inserts data into the system.
I want to make use of things like ModelState.IsValid to check for all basic validation, but this won't help me for my Setup Data mode (or any other mode that doesn't go through MVC). Is there any way I can still leverage this code, but to contain all validation in my BusinessLogic layer instead of in the controller without having the BusinessLogic layer rely on MVC?
Thanks.
It looks like this article about Service Layers has what I need. Other suggestions are still welcome. Thanks.
Note that the article on service layers still means that you need a dependency on the MVC assembly. After wrestling a bit with this myself recently, I'm now of the opinion that keeping things as separate as possible is a good design. In my model assembly, I have a services folder wherein from, say, a Create() routine, I validate and throw custom exceptions.
The service layer doesn't care who or how these exceptions are consumed. In your MVC app, map them into model state errors collections or whatever. Your design is all the more solid because your model assembly doesn't depend on some validation runner making appropriate use of MVC validation attributes, collections, etc.
I also noticed the article mentions a repository. I know it's all the rage these days but if you're already using an ORM like Entity Framework, a repository is really just a DAO. Reposity is the new Singleton.