2013-07-18 5 views
19

Если client validation делается если необходимо domain level validation?Просмотр проверки модели и проверки модели домена

Я использую ASP.NET MVC для своих веб-приложений. Мне нравится отличать мои domain models и view models. Мое модели домена содержат данные, которые поступают из моей базы данных, а мои модели просмотра содержат данные о моих представлениях/страницах.

Допустим, я работаю с данными о клиентах.

У меня будет таблица в моей базе данных под названием Customers.

я буду иметь класс клиентов, которые могли бы выглядеть примерно так:

public class Customer 
{ 
    public int Id { get; set; } 

    public string FirstName { get; set; } 

    public string LastName { get; set; } 

    public DateTime DateOfBirth { get; set; } 
} 

И я Создании вид клиента модель для представления только те данные, которые у меня есть на мой взгляд:

[Validator(typeof(CustomerCreateViewModelValidator))] 
public class CustomerCreateViewModel 
{ 
    public string FirstName { get; set; } 

    public string LastName { get; set; } 

    public DateTime DateOfBirth { get; set; } 
} 

у меня будет создать вид, что принимает мой CustomerCreateViewModel и связывает свои поля ввода моей точки зрения модели:

@model MyProject.ViewModels.Customers.CustomerCreateViewModel 

@using (Html.BeginForm()) 
{ 
    <table> 
      <tr> 
       <td> 
        @Html.TextBoxFor(x => x.FirstName) 
        @Html.ValidationMessageFor(x => x.FirstName) 
       </td> 
      </tr> 
      <tr> 
       <td> 
        @Html.TextBoxFor(x => x.LastName) 
        @Html.ValidationMessageFor(x => x.LastName) 
       </td> 
      </tr> 
    </table> 

    <button id="SaveButton" type="submit">Save</button> 
} 

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

Customer customer = Mapper.Map<Customer>(viewModel); 

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

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

Не могли бы вы поделиться некоторыми сведениями по этому вопросу?

+0

У вас есть отдельные правила проверки между слоями? Под этим я имею в виду, возможно ли иметь что-то действительное в пользовательском интерфейсе, которое не считается действительным в домене? –

+0

В настоящий момент оба должны быть одинаковыми. Я обобщаю о проверках, а не только о моих проектах. –

+1

Я бы хотел, чтобы DDD наклонялся к методу 'Validate()' для каждого объекта домена, который проверяет себя. Однако я далек от эксперта DDD. +1 за интересный вопрос. –

ответ

9

Всегда проверяйте на обоих уровнях.

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

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

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

Цели двух уровней проверки также различны. Я бы ожидал, что проверка модели представления сообщит мне все проблемы (например, пропущенное имя, фамилия слишком длинная, DoB не является датой). Однако, я думаю, было бы нормально, если логика домена завершится с ошибкой при первой ошибке и просто сообщит об этом. Опять же, для простых моделей может быть возможно собрать все ошибки и сообщить о них все обратно, однако чем сложнее приложение, тем труднее будет ожидать все ошибки, особенно если логика изменится в зависимости от данных. Но, до тех пор, пока пройдут только хорошие данные, это должно быть хорошо!

0

Вам понадобится модель валидатора, если у вас есть несколько клиентов для вашей модели. Например, если у вас есть ASP.NET MVC, вызывающий вашу модель и приложение WPF, в этом случае имеет смысл иметь логику проверки модели. Но в вашем случае, когда у вас есть только один клиент, который будет излишним.

+0

Итак, вы говорите, что если у вас есть только одно приложение, использующее вашу базу данных, то проверки на модели просмотра достаточно? –

+1

Что говорит, что если вы используете свой репозиторий только у одного клиента, то очевидно, что проверка на ViewModel будет достаточной, так как других путей доступа к репозиторию не будет, только через ваши контроллеры, которые вызывают логику проверки –

+2

Это приводит к модели анемической области. Ваша модель домена должна защищать свои инварианты. – JefClaes

2

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

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

6

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

Лучше всего начать думать о модели домена наружу (onion architecture). Обоснованием всего этого является то, что модель домена наименее вероятна со временем меняться и действует как ядро ​​приложения, изолируя слои от недостатков друг друга.

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

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

Смежные вопросы