Согласно шаблону MVVM - кто несет ответственность?

Question

Согласно MVVM, в моделях не должно быть логики. Давайте предположим, что есть модель лица, которая содержит два свойства:

public class Person { 
    public string Costcenter { get; private set; } 
    public User User { get; private set; } 
} 

Сам объект пользователя содержит другой объект, лицо, которое среди других свойств содержит свойство «Costcenter».

public class User { 
    public OtherPerson Person {get; private set; } 
} 

public class OtherPerson { 
    public string Costcenter {get; private set; } 
} 

OtherPerson это совершенно другой класс, чем Person

Сейчас мой актуальный вопрос: Кто будет нести ответственность за проверку, если Costcenter в Person равно Costcenter в OtherPerson?

Person.Costcenter == Person.User.OtherPerson.Costcenter 

Есть не так много возможностей:

1. ViewModel отвечает
2. Небольшие куски кода могут быть реализованы внутри модели
3. Проверка может быть реализован как свойство геттерного

---

public ViewModel(){ 
    [...] 
    public bool IsCostcenterEqual(Person p){ 
     return p.Costcenter == p.User.OtherPerson.Costcenter; 
    } 
} 

---

public class Person { 
    public string Costcenter { get; private set; } 
    public User User { get; private set; } 
    public bool CostcenterEquals(){ 
     return this.Costcenter == this.User.OtherPerson.Costcenter; 
    } 
} 

---

public class Person { 
    public string Costcenter { get; private set; } 
    public User User { get; private set; } 
    public bool IsCostcenterEqualProperty{ 
     get{ 
      return this.Costcenter == this.User.OtherPerson.Costcenter; 
     } 
    } 
} 

На данный момент я не уверен, если это просто вопрос мнения, но я ищу лучший * способ решения этой проблемы

*) наилучший = лучший монтаж, связанный с шаблоном MVVM

Edit 1

Я забыл упомянуть, что я хотел бы использовать свои модели для EF (если это имеет значение)

Answer 1

Как показывают другие ответы и комментарии, это тема, которая вызывает много страсти и мнения. Нет никакого «правильного» способа сделать это.

Вы можете принять позицию, согласно которой модель представляет собой всего лишь набор DTO/POCOs или что бы вы ни назвали. Затем ваши слои настойчивости и бизнес-логики живут внутри ViewModel.

Вы можете принять позицию, согласно которой модель представляет собой слой постоянства, отвечающий за сохранение только DTO и что бизнес-логика живет в ViewModel.

Вы можете принять позицию, что ViewModel несет ответственность только за обработку логики просмотра (поведение приложения), и что бизнес-логика и постоянство существуют в модели.

Вы можете занять позицию, которая ... и так далее. Вы можете применить подход к модели анемической модели данных; или подход с богатой моделью данных и т. д.

Нет ни одного правильного способа справиться с этим. Потеряны одинаково допустимые способы. Двумя ключевыми моментами для всех подходов являются:

1. Решите подход и придерживайтесь его. Будьте единообразны во всем решении.
2. Убедитесь, что слои правильно развязаны независимо от выбранного подхода.

Answer 2

Модель может и должно содержать бизнес-логику. ViewModel не должен содержать никакой бизнес-логики, просто логики, связанной с представлением.

Answer 3

Думаю, у вас здесь больше уроков, чем вы думаете. Классы ViewModel выполняют аналогичную работу с контроллерами в MVC. У них не должно быть логики вашего бизнеса в них, но они должны координировать классы, которые делают, что является вашей логикой приложения.

Итак, у нас есть «Логика приложений», которая контролирует пользовательский интерфейс, связывает данные с представлением и выполняет интеграцию между тем, что делает пользователь/видит и «Бизнес-логика», которая реализует правила и инварианты вокруг него.

Если у них вообще не было логики, они были бы объектами передачи данных и мало полезны (DTO буквально предназначены для перемещения данных по известной «форме»).

Бизнес-логика обычно будет либо «Сценарии транзакций» (часто мы реализуем это как вещи, такие как IPersonService или IEmployeeService и т. Д., С методами, такими как IEmployeeService.HireNewEmployee(args]), или, если ваш домен достаточно сложный для этой части системы, Модель предметной области.

Какой бы путь вы идете, вы обнаружите, что эти классы, реализующие бизнес-логику будет вызываться по ViewModels.

Answer 4

как правило, проверка выполняется на обоих ViewModels и моделей. ViewModels, как правило, учитывая логику, связанную с бизнесом, а валидация моделей используется исключительно для того, чтобы убедиться, что ее данные имеют смысл. Например, gender должно быть подтверждено на Person Модель. Это потому, что это факт, что пол может быть только male или female, независимо от того, что такое бизнес-логика.

Answer 5

Для этого конкретного сценария логику можно добавить в View Model.

Помните responsibilities-

Модели - любую логику, которая является бизнес-логикой и является правилом для этой конкретной модели или юридического лица, то, что логика должна быть помещена в модели. например - если у вас есть компания, называемая «двигателем», фактические предприятия двигателя, которые являются оперативными данными о том, как быстро газ перекачивается, все основные операции выполняются в классе двигателей, который является моделью

View Model - любая логика, которая используется для выполнения манипуляций, чтобы показать соответствующие данные в UI.

Теперь, как этот движок должен выглядеть, какие манипуляции вам нужны для управления пользовательским интерфейсом, не влияет на его работу и связан только с пользовательским интерфейсом, поэтому эта логика и детали должны входите в View Model.