What to write in Model, what to write in View Model and what to write in Controller

Question

I have to start a business application project. I am planning to use MVC5, Entity Framework Database first Approach.

My question is where we have to write the following logic's?

Validation Logic (Data annotations/Remote Validations/Custom Validations etc) -> Model?, ViewModel? or Controller?

Business Logic's (CURD Operations, Custom validation functions/methods, functions for drop down/List/Grid filling etc) -> Model?, ViewModel? or Controller?

Note:- The Classes generated by EntityFrameWork cannot be editable in database first approach, In Remote validation attribute we have to specify the method name which is exist in the controller

Answer 1

Validation logic - belongs in the Model, and Data Annotations should be used for this purpose - http://msdn.microsoft.com/en-us/library/ee256141(VS.100).aspx. The reason it is preferable to put validation logic in the Model is that it allows you target all instances with the validation logic. E.g. if you have 5 Controller actions which use a specific model, you'll only need to update the validation logic in the Model (rather than in 5 seperate action methods).

http://www.pluralsight.com/training/player?author=scott-allen&name=mvc4-building-m5-data-ii&mode=live&clip=6&course=mvc4-building

However, coming back to your statement:

Note:- The Classes generated by EntityFrameWork cannot be editable in database first approach, In Remote validation attribute we have to specify the method name which is exist in the controller

I can see where you're coming from, since your data annotations woud be wiped out whenever the generated classes were regenerated by EntityFramework/the T4 templates.

Assuming this is what you meant, I suggest you take a look into EF MetaData classes as described here (see the Add metadata classes heading): http://www.asp.net/mvc/tutorials/mvc-5/database-first-development/enhancing-data-validation

These help to address this particular scenario by separating the DataAnnotations for each field from the Model.

I can see the case for adding validation DataAnnotations to ViewModels instead.

E.g. if you wanted to have a Model with 5 fields, but only allow 3 of them to be bound to a Controller, you could create a ViewModel with only the fields to be bound (e.g. to avoid 'Overposting'/'Mass Assignment') and then set the appropriate DataAnnotation attributes. The down-side is that you would then have validation logic specified in more than one place, so consider using the [Bind(Exclude = "field1,field2")] attribute wherever possible - see http://www.pluralsight.com/training/player?author=scott-allen&name=mvc4-building-m5-data-ii&mode=live&clip=5&course=mvc4-building

Business Logic - CRUD operations definitely belong in the Controller. You may even want to separate the CRUD operation methods into a separate repository layer as described here: http://www.asp.net/mvc/tutorials/getting-started-with-ef-5-using-mvc-4/implementing-the-repository-and-unit-of-work-patterns-in-an-asp-net-mvc-application

In terms of getting data for editors (drop-down lists etc.): if you're planning to use a control repeatedly, consider writing an Editor Template as described here: http://www.codeproject.com/Articles/672591/Exploring-Display-and-Editor-Templates-in-ASP-NET

EDIT: here is a good eample for creating a custom 'HoursOfTheDay' Editor Template and using this via the [UIHint("HoursOfTheDay")] DataAnnotation - http://www.devcurry.com/2013/04/custom-templates-in-aspnet-mvc.html

Otherwise, I'd probably load this data (e.g. your list of options) into the ViewModel or Model from the Controller.

Custom Validation belongs in a custom validation DataAnnotation in your Model or Model MetaData class as described here: http://www.pluralsight.com/training/player?author=scott-allen&name=mvc4-building-m5-data-ii&mode=live&clip=7&course=mvc4-building

Hopefully that answers your questions.

As an aside, that whole Pluralsight course is very good (and also free): http://www.pluralsight.com/courses/mvc4-building

Answer 2

You should follow the basic MVC architecture. You can write your validation logic in view model not in data model. you can write business logic in your Controller or use a reference from your controller itself. Don't make complicated architecture. First you understand your need properly, design based on that.

Answer 3

In Model you have to write your classes. In View you have to write your design. In controller you have to write your logical coding.

In MVC view you can write inline coding. So you can write your code inside view also. Two type of view is there, i will prefer Razor view.

Example:

In model(Name:mymodel):

               public class mymodel
               {
               public string myname {get; set;}
               }

In View (Name: firstproj):

              @model myproject.mymodel
              <html>
              <div>@Model.myname</div>
               </html>

In Controller(Name : Homecontroller):

              public ActionResult firstproj(mymodel m)
              {
              m.myname="Sukesh Chand";
              return view(m)
              }

Answer 4

I suppose all of your logic should be in the model. The view should only handle how to display information, whatever that information may be. The controller links the view to the model and delivers the information from the model to the view. It also handles any time the information displayed need to be changed.

I hope this helps.

EDIT

In MVVM, the actual view is directly connected to the controller. The ViewModel is updated by the model and then updates the controller. These images compare MVVM and MVC:

MVVM:

MVC:

Theres is a full article here that describes MVVM, but in an objective-C context. If you need further help, refer to it.