I have four layer solution a medium size project:
Model (EF POCO entities)
Data (EF ObjectContext)
Services
asp net MVC question
a)Should i have validation attributes- Dataanotation in Models or MVC project?
b)where should i set ViewModel-s if in MVC then where do i fill ViewModels with data, in Controller? else if on other project should create Repository for VewModel?
c) should ViewModel have validation>?
A, C) If you have view models that are different from your DTOs, then you might prefer to use DataAnnotations in both types. This way, you can validate before you try to persist and again as you persist in case your DTOs are used outside the scope of your MVC app.
B) I usually tuck my view models into the Models folder of my MVC app and my DTOs into a data project that is separate from my MVC app. I use AutoMapper a LOT to copy values between my view models and my DTOs.
It's okay to have validation on Models and ViewModels. It's on you what you like more, but it's better to have validation on ViewModels (you don't need to use binding and so), but there is more work with creating lot's of ViewModels when Models can be used too.
I really prefer to create two folder inside the models:
One is for Database model class and another is for view models.
You can also add all type of validation into the database model class.
Related
Consider that I have DTO for view. At domain layer we have the entity . We can use automapper to fill the DTO from entity. But do we need to perform all these at application service class or can we have method at Model which can be called by Controller to perform this process. I need to know the class structure for MVC
Regarding adding the mapping methods to Models, I would disagree and suggest to keep the Entity classes as simple as possible (POCO). I personally prefer to do the mapping either at Application Service Layer or in ViewModels.
I m new to MVC and will appreciate if you can clarify my question.
What is a model?
Is it just Poco class having fields/ properties, for example a Person class?
Or is a model a data structure having data in it, for example List<Person> or List<Users> ?
Or as per asp.net a working Model is a business layer or service layer, can have business rules, logic, validation and i can talk to other layers?
Thanks for your help and guiding me.
There are ViewModels and DataModels. Poco models are considered the DataModels.
Poco models can also be used as ViewModels but its better to use separate models for views. Because a ViewModel can consist of one or more Poco models.
Here you will find more details: http://rachelappel.com/use-viewmodels-to-manage-data-amp-organize-code-in-asp.net-mvc-applications
One important note "Model" in "ASP.Net MVC" is different than "Model" in classic MVC design pattern, so be careful when looking for definition/resources. "Model in classic MVC" covered in How should a model be structured in MVC?.
"Model" in ASP.Net MVC is object (usually class) that ideally provides all data needed to render particular view.
There is no restrictions on whether such object used for any other purpose. If you view shows one particular item from data access layer (like Person) you can easily share the same object in data access layer and use it as view model.
Note that as of MVC5 views can't call methods asynchronously, so it is good idea to make sure all data is present in the model class instance rather than letting view to call DB/other remote services.
I am trying to understand the concepts of a good designed project.
I am using ASP.NET MVC and i am trying to create a layered (pluggable) project.
The current project structure what i have now is this:
LayeredProject - the MVC Project containing Controllers
LayeredProject.EntityFramework - contains all the POCO classes used for database. (i am using Code First approach)
LayeredProject.Model - this should contain all the business objects used in the project.
Saying that the project is a eCommerce website, i would structure it like this:
In the LayeredProject.EntityFramework project i have classes which corresponds to the database tables. Category, Product, User. This project is used only for saving and loading data from database, and those objects should not be used for other purposes. This project has a reference to LayeredProject.Model project.
In LayeredProject.Model project i store all the objects i work with, which most of them are exactly copies of LayeredProject.EntityFramework POCO's objsects and some other Services Classes used.
In LayeredProject i keep all my ViewModels classes, Controllers, and different UI logic. This project has a reference to LayeredProject.Model project.
First of all, i am not sure that this is the right way of doing this.
And, it this is the right way of doing it, then i get a little confused because i will have a duplicate of my POCO classes in EntityFramework project and also on Model project.
Please help me understanding this
You can Design Your Project using layered structure as well using MVC. The Controller and view part should stay intact. You can divide the business logic part as many layers as you want. The model should come as a result of the number of layers you are expecting. For this keep your business logic in a separate project (not neccessary: it can be there in web project itself), refer the dlls from that project to the MVC web solution. Pass the models which are generated as a result of database querying to the web solution and with the help of controller render the view.(I have done my project using this style)
The MVC project should contain:
view models: models for the views, i.e. models that are very specific to render each view (these model are not the M in MVC). This models usually contain the data which must be shown or edited in the view, as well as aditional necessary information to render the view: for example, if the view must render Drop Down Lists, the view model should contain the corresponding SelectList or IEnumerable to populate the list. You can use mappers, like AutoMapper or ValueInjecter to move data from the business entities (entities coming from the Business Layer) to the view models, and viceversa. Or if appropriate, you can use directly the business entities as properties in the model view (the view model doesn't need to be flat: it can contain objects as properties)
views, strongly typed with the view models
controllers: this controllers use the Business Logic (that is the Model, the M in MVC) to control the application flow, to create and provide the model views for the views, and to react to the user actions
UI helper: I usually add this layer to fulfill the DRY principle. I.e. if I have to prepare a SelectList and it's going to be used in many views, I do it in this layer, and use it from all the necessary places. This can include calculations, orderings, or anything tighly related to the UI, so it doesn't fit in the Business Layer (Model). This uses the Business Layer, and provides data specific for the Views.
Those are the specific and critical parts of MVC, which includes the VC in MVC (views and controllers) The M in MVC (Model) is the business logic which can be done 'as usual'. I.e. you don't have to do anything special in your business layer to use it with MVC. You can use the technology of your choice (a traditional DAL + BLL, WCF, WS, or whatever you want).
This is something which works well for LOB applications. Of course, if you're making a toy application, you can forget this all and make something more monolythic. But I only recommedn this for very little applications with scarce maintenance needs.
These are examples of objects in several layers that allow to edit a "Pet":
Business Logic Layer:
PetService, a class which can be use to read, write, find, and modify pets (as explained above it doesn't matter how this is implemented)
Business Entity: it's the BLL entity for managing Pets. This could be a POCO object or a DDD entity:
Pet - int Id, int PetTypeId, string Name...
View Model: contains a Pet proerty, as well as a list of PetTypes, so that the view can render a drop down list for the PetTypeId:
PetViewModel - Pet ThePet, SelectList PetTypes
UI Helper: if the PetTypes is going to be used in more than one or two views, a PetUiHelper could provide this select list for all the views that require it:
PetUiHelper - GetPetTypesList()
Pet views: a strongly typed view for PetViewModel
Views\Pet\Edit.cshtml
PetController: uses the PetService to create the views, and their model views.
PetController - Edit(int id) --> returns an Edit view, woth its corresponding PetViewModel. There must be also an HttpPost Edit action which receives the user input in an specific model or the PetViewModel, or the Pet plus the Id or whatever. This depends on what you're editing.
Finally, if you know how to use DI, you can use Unity.Mvc or any of the other options to inject the Business Services in the controllers.
seems your using the Code First approach to build a data access, you can dig in this extensive article and gain more insight.
http://ofps.oreilly.com/titles/9781449320317/ch_AdvancedData.html
You probably have one too many layers in there, there should be no reason to separate the model with the business logic from the LayeredProject MVC layer itself unless you are planning to have a client app or some other separate project to access the model. In the MVC project you already have a model folder that can be used for that. However in the MVC project you should also add a "ViewModels" folder to keep models that are specifically used for the view concerns (e.g. DTO objects).
This project shows a nice simple way of keeping the things separate simply within folders in the MVC project: RacoonBlog Project. Although it uses RavenDB rather than EF the ideas are the same.
Most MVC apps I have worked were layered in this way
MVC Project: Had the controllers, views and models. The business logic resides in the model.
The Data Access layer (Persistence layer) : This project uses an ORM. (In your case entity frame work)
Classes that are mapped to the database tables reside in the Model and not the data access layer.
I’m building a project that currently has 3 assemblies:
UI
Core (Services & Models, Utilities)
Repositories (Linq2SQL)
Dependencies are
UI -> Core
Core -> Repositories.
I’d like Services and Models to be in their own assemblies and end up with something that’s built around the Models i.e.:
UI ->Models, Services
Services -> Models, Repositories
Repositories -> Models
Models
The system I’m building is basically a website CMS so I’ll have a model for a web page (PageModel) which has a collection of child web pages. PageModel can call methods in a service (PageService) to populate its child pages but in the new design that can’t happen because the Models assembly necessarily knows nothing of the services assembly.
I’ve considered some of the ideas in the Onion Architecture (namely dependency injection) to solve this, but it seems that a more elegant /obvious solution might be available.
Do I need to introduce another layer of Model? View Models? I think what I’m calling Models are Domain Models... I may very well be wrong! Services would then be Domain Services?
So my solution would be:
UI -> Services, ViewModels, Models
ViewModels -> Services, Models
Services -> Repositories, Models
Repositories -> Models
Models
In this example I imagine my PageViewModel would extend PageModel and use the PageService to fetch it’s child pages..
Any suggestions appreciated. Also any pointers on what these layers of models are usually called? Am I talking about DTO Models rather than Domain Models here? And Domain Models rather than View Models? It seems like what I'm proposing to use the View Models for isn't really the job of a View Model..
Thanks
EDIT:
Something I hadn't mentioned originally is that my Domain Models aren't basic translations of single database entities like you tend to see in most tutorials. A domain model can contain data fields that come from several related database tables.
So would it be worth having a set of Models purely to encapsulate the the data in the Domain - without any methods/properties that fetched related objects or saved the object back to the DB etc? - Data Transfer Objects.
From looking at a couple of scribbled diagrams this would mean having a set of mappers in the domain layer (which seems wrong..) to translate DTO models to Domain Models and back. The project would become built around the DTO models rather than the domain models but given what's encapsulated by the DTOs I don't see that being a problem.
For anyone who's interested, the proposed dependency structure would be like so:
UI -> Services, Domain Models
Services -> Repositories, Domain Models, DTO Models
Domain Models -> Repositories, DTO Models
Mappers -> Domain Models, DTO Models
Repositories -> DTO Models
DTO Models (no dependencies)
It's a bit of a mess! And all just because I want my PageModel to be able to fetch its own child PageModels.. It's looking like having a go at dependency injection might not be such a bad plan.
Thanks to the guys who've replied. You've given me loads to think about.
You can accomplish this just fine with the onion architecture.
I'll have for example:
UI, Domain, Data Access, Services
UI
Services
Data Access
Domain (contains view models as well)
UI can access any one.
Services, only data access and domain.
Data access - only domain.
My repository interfaces are in the domain project, and they are implemented in the data access project.
I also keep other interfaces in the domain project (IContext, IUnitOfWork, etc) so I have one central place and not spreading too many interfaces between projects.
DTOs would be used simply for transferring between layers, if you deem appropriate. There's no reason to me you can't pass a domain model from a data layer on up, some choose to only use DTOs here. I'll do the mapping in the UI layer (ex MVC controller) to a ViewModel since I can make use of AoP to do it for me ([AutoMap()] attribute )
Just remember that your models should not contain any persistence logic at all.
I think it is pretty typical of any "real world" application to store data differently than is displayed on the screen. I think you are on the right track, with having 2 seperate "models". I usually end up calling them:
ViewModels - map to what is displayed on the screen, what the views want.
DataModels - map to the DB, what the persistence layer (ORM) wants.
Sometimes the DataModels are called Entities especially when talking about Entity Framework as a data access layer, or Data Transfer Objects (DTOs).
Usually there is some set of "translators" to map from the view to the data models too, or sometimes AutoMapper can be used.
Of course if what you are displaying is close enough to your data structure, there is no harm is passing all the persistence / data models to the Views, but I like to keep them separate too.
I’ve considered some of the ideas in the Onion Architecture (namely dependency injection) to solve this, but it seems that a more elegant /obvious solution might be available.
Once you get the hang of using Dependency Injection correctly, it's really a very elegant/obvious solution.
I'd suggest a dependency structure like this:
UI
Controllers -> Services, Models, ViewModels
Views -> ViewModels
ViewModels (no dependencies)
Services -> Repositories, Models
Repositories -> Models
Models
This is pretty close to what you had before, but your ViewModels are a part of your UI project and have no dependencies at all. They should just be simple classes that represent what you want to show to the user.
It's the Controller's job to:
Invoke the services to get the Models,
Translate the models into ViewModels, and
Invoke the View code
Views should not require any information that isn't provided by the ViewModels.
Right now I am using classes generated in the .dbml file and passing the data to the controller through an implementation of the repository pattern. My question is this, do I need to create classes that are essentially clones of the classes from the .dbml without the linq-to-sql and without certain flags, or the ID to have the proper separation of domain logic?
The clones you are referring to have a name: view models. And yes, you absolutely should be using view models. They are tailored to the specific requirements of a given view. The controller should then query the repository in order to fetch some domain models (autogenerated Linq-To-Sql class, EF entities, ...) and map them to a view model class which will be passed to the view. That's how IMHO every properly architected ASP.NET MVC application should be designed. You should not pass domain models to a view, nor receive any domain models as action parameters from a view. Only view models.
View models are not clones of a domain model. A view model could be mapped out from multiple domain models, or one domain model might break into multiple view models. This way the views have the full flexibility to represent the data independently of the way this data has been transported in the business layers.