Что должно быть в моих моделях?

Question

Я бизнес-модель, названная Product и Category, как показано ниже, в которой я добавляю валидации:

public class Product 
{ 
    public int ProductId {get; set;} 
    [Required] 
    [StringLength(25)] 
    public string Name {get; set;} 
    public string Description {get; set;} 
    public int CategoryId {get; set;} 
} 

public class Category 
{ 
    public int CategoryId {get; set;} 
    public string Name {get; set;} 
} 

Для модели представления я создал что-то вроде этого:

public class ProductViewModel 
{ 
    public Product Product {get; set;} 
    public IList<Category> Categories {get; set;} 
} 

Моего друг предложил сохранить все проверки в модели представления и отображение всех свойств бизнес-модели в модели вида следующим образом:

public class ProductViewModel 
{ 
    public int ProductId {get; set;} 
    [Required] 
    [StringLength(25)] 
    public string Name {get; set;} 
    public string Description {get; set;} 
    public int CategoryId {get; set;} 
    public IList<SelectListItem> CategoryDropdownValues {get; set;} 
} 

Я спросил его о преимуществах этого подхода к вышеупомянутому, он был не очень уверен. Но он настаивал на том, что вы не должны использовать бизнес-модели непосредственно в своих взглядах и что только модели просмотра должны быть проверены.

Мои вопросы:

• Должен ли я сохранить свою логику проверки в поле зрения модели или бизнес-модели?
• Плохо ли, что модели просмотра зависят от бизнес-моделей?

Answer 1

Ваш друг справа. О ваших вопросах

1. Подтверждение правильности ввода и проверки бизнес-правил. В большинстве случаев проверка правильности ввода является частью проверки бизнес-правил, однако в asp.net mvc фреймворк выполняет эту проверку автоматически. Во избежание дублирования это означает, что проверка подлинности пользовательского интерфейса должна использовать проверку бизнеса. Это можно легко сделать с помощью FluentValidations (аннотации данных слишком жесткие IMO).

   Таким образом, в этом случае выполнение пользовательского интерфейса выполняется на уровне пользовательского интерфейса, используя проверку бизнес-модели.

2. Просмотреть модели всегда в зависимости от бизнес-модели, по крайней мере, до определенной степени, но нет ничего общего. Это разные модели с различными целями, поэтому их следует разделить. Тот факт, что, вероятно, ваша модель взгляда на 90% идентична модели бизнеса (ну, структуры данных), является просто совпадением. Мы хотим сохранить каждую модель в своем собственном слое, и просто случается, что у них одинаковые свойства.

Answer 2

Держите проверку на самом нижнем уровне, насколько это возможно, это классы. Так MVC проверяет проверки автоматически.

Answer 3

Я бы сохранил валидацию в модели представления. Здесь MVC получает свои метаданные. Кроме того, атрибуты проверки определены в сборках MVC. Вы не хотите добавлять зависимость MVC к своей бизнес-логике или к чему-либо, кроме пользовательского интерфейса. Модели пользовательского интерфейса могут зависеть от бизнес-модели, но не наоборот. Я также предлагаю вам ознакомиться с некоторыми статьями лучших практик, например: http://blogs.msdn.com/b/aspnetue/archive/2010/09/17/second_2d00_post.aspx

Answer 4

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

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

Структура ASP.NET MVC будет правильно анализировать и проверять атрибуты из System.ComponentModel.DataAnnotations namespace. Вы можете использовать их для комментирования своих моделей доменов, и при необходимости вы можете при необходимости увеличить свою презентационную модель, используя компоненты, ограниченные структурой MVC.

Answer 5

Вообще говоря, ваш пользовательский интерфейс должен ссылаться на модели просмотра, а ваши модели просмотра должны быть оберткой вокруг ваших моделей. Задача модели состоит в том, чтобы моделировать бизнес-объект, задача модели представления - адаптировать эту информацию, чтобы она могла быть представлена ​​в пользовательском интерфейсе.

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

Для подтверждения я согласен с тем, что вы, вероятно, хотите, чтобы на самой модели; это означает, что модель всегда проверяется независимо от того, где она отображается.

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

Answer 6

• проверка должна быть выполнена в вашей бизнес-уровне
• Не подвергайте бизнес-модель непосредственно в пользовательский интерфейс

Итак, как вы подтвердите ввод в пользовательском интерфейсе тогда? -Да, вам нужно в некоторой степени дублировать проверку, используя атрибуты DataAnnotations на моделях просмотра MVC. Я думаю, что это лучше подходит для SRP, поскольку это не то же самое, что проверять ввод в Интернете и проверять бизнес-правила.