DDD и проверка на стороне клиента - PullRequest
Новая
       29

DDD и проверка на стороне клиента

7 голосов
/ 06 августа 2011

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

  • Solution.Model
  • Solution.Repository
  • Solution.Services
  • Solution.Presentation
  • Solution.UI.Web

Уровень взаимодействия с пользователем будет Solution.UI.Web, и мы будем предполагать, что это будет приложение ASP.NET WebForms. Как вы применяете проверку на стороне клиента?

Есть несколько вещей, которые следует учитывать:

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

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

Одним из простых подходов было бы реализовать логику проверки с использованием объектов ViewModel (плоских представлений объектов вашего домена, которые будут отправлены клиенту), а затем проверять эти объекты перед попаданием на серверы приложений / баз данных.

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

Теперь инфраструктура ASP.NET MVC значительно упрощает жизнь. Вы можете использовать EF + DataAnnotations, а инфраструктура MVC Scaffolding может сделать большую часть работы за вас. но это тот случай, если вы хотите создать приложение MVC и реализовать логику валидации с помощью jQuery и JavaScript.

Но что, если вам нужен более общий подход для реализации инфраструктуры проверки, которая может использоваться и использоваться в различных приложениях, например, WinForms и WebForms?

Просто чтобы уточнить, что мне нужно, это набор шаблонов / принципов и / или методик / структур проектирования для реализации структуры валидации, которая может быть реализована с использованием вашей доменной модели и затем применена в ваших клиентских приложениях. И я не хочу просто возвращать коллекцию сообщений об ошибках строк о нарушенных правилах или о чем-либо еще, я хочу иметь возможность обновлять свои связанные с данными элементы управления (TextBox, ComboBox, DateTimePicker и т. Д.) При сбое проверки, чтобы слой пользовательского опыта будет более интуитивным (если хотите).

Я видел некоторые реализации и фреймворки здесь и там, и некоторое время я использовал проверку на стороне клиента ASP.NET MVC, поэтому мой ответ не имеет ничего общего с проверкой MVC или JavaScript.

Ответы [ 3 ]

5 голосов
/ 11 августа 2011

В DDD домен обычно самопроверка.Другими словами, объектам запрещено находиться в недопустимом состоянии.Значимые объекты здесь очень помогают.Они просто инкапсулируют правила форматирования.Например, у вас может быть класс ZipCode , который гарантированно всегда будет правильно сформирован.В качестве дополнительной ответственности он может иметь статический метод, такой как ZipCode.TryParse или ZipCode.Validate , который будет принимать произвольную строку в качестве параметра и проверять правильность.Таким образом, логика проверки сосредоточена в одном месте.Если ваши доменные объекты доступны непосредственно из пользовательского интерфейса, вам не нужно дублировать эту логику где-либо еще.Это касается толстых клиентов (Windows Forms, WPF).К сожалению, нет способа избежать некоторого дублирования для веб-клиентов, когда они должны выполнить проверку без обратного переключения на сервер.

4 голосов
/ 07 марта 2015

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

Я пишу об этом в моем примитивном одержимости посте в блоге.Вот как может выглядеть ваш контроллер ASP.NET MVC, если вы создаете такие классы: 

public class CustomerController : Controller
{
    [HttpPost]
    public ActionResult CreateCustomer(CustomerInfo customerInfo)
    {
        Result<Email> emailResult = Email.Create(customerInfo.Email);
        Result<CustomerName> nameResult = CustomerName.Create(customerInfo.Name);

        if (emailResult.Failure)
            ModelState.AddModelError("Email", emailResult.Error);
        if (nameResult.Failure)
            ModelState.AddModelError("Name", nameResult.Error);

        if (!ModelState.IsValid)
            return View(customerInfo);

        Customer customer = new Customer(nameResult.Value, emailResult.Value);
        // Rest of the method
    }
}

Нет необходимости использовать аннотации, потому что они по сути побуждают вас дублировать логику проверки.

Сравните этипримеры кода:

2 голосов
/ 08 августа 2011

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

Тем не менее, модель проверки в ASP.NET MVC является расширяемой, и вы можете расширить ее для поддержки дополнительных правил проверки или события в рамках структуры проверки, отличной от DataAnnotations. Здесь является примером интеграции блока проверки библиотеки предприятия с ASP.NET MVC, однако, как указывается в статье, проверка на стороне клиента не была реализована. Другой подход заключается в использовании атрибутов DataAnnotations на уровне вашего домена. Пространство имен DataAnnotations не связано с ASP.NET MVC.

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

Платформа Fluent Validation может использоваться в качестве отправной точки для всеобъемлющего решения для проверки. Существует множество примеров использования этой инфраструктуры с ASP.NET MVC.

...