Can a Model communicate with other Models, for my case, can a Model have a list of an other Model, Example :
I have a Model called Graph, and a Model called Node.
Is it appropriate in the MVVM pattern to make the Graph class which is a Model, contain as a property, a list of the Model Node ?
Yes.
MVVM is simply a separation of concerns in terms of views and data. Views can have other views and models can encapsulate other models. The view model is the hybrid where data is stored and acquired using the models and consumed by the views.
Although the answer might be yes you do have to consider the 'proper' responsibilities in MVVM. As long as the Model maintains integrity of the model (references, domain/validation checks) it is perfectly fine to have the model classes 'communicate' with each other. However, in general, I prefer the ViewModel and the repositories to be responsible for retrieving data and translating it into ViewModel classes.
Many times I do not need any logic in the model, the model is the structure I receive from and send to the data store (file, db, web service, ...) The model is 'just' data to me and preferably generated (proxy generation, Entity Framework, ...)
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'm using Entity Framework 5 with MVC 4. I used the DbContext Fluent API to create POCO entities.
Let's say that in a specific View, I need access to two or more entities.
What I typically do is create new folder called ViewModels and create a superclass. Then, I simply copy the POCO entities into this superclass to use it in my View.
However, I was trying to think of a way to take advantage of the scaffolding when adding a Controller & View for the superclass inside that ViewModels folder because now, that folder is not part of the EDMX ORM model which the Model Class (in the window) tries to access and put in the list when the Scaffolding option is set to "MVC Controller with read/write actions and views using Entity Framework".
Obviously, many times you'll need a composite of entities to work with in a View rather than just one.
Is there a way to do this, or is the CRUD simply set up only for one entity per View?
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 have a website that has the views generated directly from objects created by Entity Framework. After reading this blog by Scott GU it seems the best way to get DataValidation to work is to have started with POCO objects instead. (search for the word Buddy Class on the link)
Can I auto-generate my buddy classes somehow? Or did I start my foray into MVC on the wrong foot?
Or did I start my foray into MVC on the wrong foot?
I am afraid that this might be the case and the following sentence confirms it:
I have a website that has the views generated directly from objects created by Entity Framework
You shouldn't use your EF models in the views directly. It is considered good practice to have view models. Those are classes that are specifically designed to the needs of a given view and could contain formatting and validation. A typical scenario might be the following:
A controller action is requested
The controller queries the repository to fetch a model (EF model if you will)
The controller converts this model into a view model using a mapping layer (this could be easily achieved with AutoMapper).
The controller passes the view model to the view
This scenario works also when a controller action receives a view model from the view, checks whether the modelstate is valid, maps it back to a model and passes the model to a repository.