Должен ли я иметь эту логику в модели представления?

Question

Я использую ASP.NET MVC и не уверен, что логика, которая у меня есть в моей модели просмотра, уместна. Вот посмотреть пример модели:

class ViewModel { 
    public string prop1 {get; set;} 
    public string prop2 {get; set;} 
    List<string> prop3 {get; set;} 
     .......... // more properties 


    public ViewModel() { 
     prop1 = DataModel.field1 
     prop2 = DataModel.field2; 

     prop3 = UtilityClass.complexFunction(); 
     ...... 
    } 
} 

Проблема заключается мой взгляд модель имеет много свойств, и я подумал, инициализации их в контроллере, но, кажется чище инкапсулировать заселение свойств в модели представления чтобы контроллер был более компактным. Если я должен делать это в контроллере, в чем же причина? Я думаю, что этот подход будет примерно таким:

ViewModel model = new ViewModel() {prop1 = DataModel.prop, prop3 = UtilityClass.complexFunction()} 

Answer 1

Неправильно объявлять эти свойства в контроллере.

Как вы используете MVC. У вас должно быть 3 разных слоя. Так что ваш код должен быть разделен на Модель

class Model 
    { 
    public string prop1 {get; set;} 
    public string prop2 {get; set;} 
    List<string> prop3 {get; set;} 
    // more properties 
    } 

Контроллер должен только быть ответственным, чтобы связать свой вид и модель

class ViewModel 
{ 
    //Use Instance of Model in here 
    public ViewModel() // OR pass model as dependency injection 
        //so that you can use it for Unit Testing 
    { 
    prop1 = DataModel.field1 
    prop2 = DataModel.field2; 

    prop3 = UtilityClass.complexFunction(); 
    ...... 
    //Do not put this Conversion of DataModel to Model assignment logic in 
    //View Model's constructor write mapper file or something to convert Data Model to Model 
    } 
} 

Answer 2

Контроллер должен инициализировать объект ViewModel, как вы думали:

ViewModel model = new ViewModel() {prop1 = DataModel.prop, prop3 = UtilityClass.complexFunction()}; 

Таким образом, класс ViewModel теперь не связан с классом DataModel и UtilityClass как в вашем другом подходе. Класс ViewModel теперь может работать изолированно, без необходимости знать что-либо о нем или в зависимости от DataModel или UtilityClass. Это упрощает проверку класса ViewModel.

Answer 3

Как насчет модели наследования?

public class ModelAddress 
{ 
    public String Line1 { get; set; } 
    public String Line2 { get; set; } 
    public String City { get; set; } 
    public String State { get; set; } 
    public String Zip { get; set; } 

} 

public class ViewModelAddress : ModelAddress 
{ 
    public WhizzyWhig WW { get; set; } 
    public FancyWhatzitUIProperty FwUp { get; set; } 

    public ViewModelAddress(ModelAddress copy) 
    { 
     this.Line1 = copy.Line1; 
     this.Line2 = copy.Line2; 
     this.City = copy.City; 
     this.State = copy.State; 
     this.Zip = copy.Zip; 
    } 
} 

Answer 4

Типичная модель используется при создании классов баз данных (моделей данных) с каркасом сущностей, который используется для генерации таблиц в базе данных.

По модели в asp.net mvc View мы подразумеваем, какой класс (модель представления) мы собираемся связать. Это может быть тот же класс модели данных, который будет вести себя как модель представления, если ничего нового не будет добавлено для этого представления для анализа данных и т. Д., Иначе можно создать другую модель представления для привязки к представлению. Все, что происходит от базы данных, используется в модели, в то время как в модели модели вы можете анализировать эти данные или делать что-то для привязки к представлению.

Ниже приведен пример использования этих двух моделей.

class Student { 
      //DataModel 
} 

class StudentViewModel{ 
    public Student stu = null; 

    public StudentViewModel(Student s){this.stu = s;} 

    public void DoParseOrSomeFuntionHere(){} 
}