Как оставаться СУХИМЫМИ с валидациями в объектах и ​​сервисах Домена против валидаций на уровне пользовательского интерфейса - PullRequest
Новая
       29

Как оставаться СУХИМЫМИ с валидациями в объектах и ​​сервисах Домена против валидаций на уровне пользовательского интерфейса

3 голосов
/ 27 мая 2011

Я искал ответы и даже задавал несколько вопросов на эту тему, но пока не нашел правильного ответа. Как я могу представить методы проверки в моих объектах и ​​сервисах POCO Domain для уровня UI? В настоящее время я использую веб-формы.

Например, у меня есть следующий объект домена: 

class Person
{
    public string Name { get; set; }
    public string Email { get; set; }

    public bool IsValidEmail(string email) {}
    public bool IsValidName(string name) {}

    public bool IsValidPerson()
    {
        if (IsValidEmail(Email) && IsValidName(Name)) { return true; }
        return false;
    }
}

и служба домена: 

class PersonService
{

    private Person person;
    private PersonRepository pRepo;

    public PersonService()
    {
        person = new Person();
        pRepo = new PersonRepository();
    }

    public AddPerson(Person p)
    {
        if (p.IsValidEmail(p.Email) && p.IsValidName(p.Name) && !DoesEmailExistInDatabase(p.Email))
        { pRepo.Save(p); }
        else
        { throw new ArgumentException(); }
    }

    public GetPersonByEmail(string email)
    {
        if (person.IsValidEmail(Email))
        { pRepo.GetByEmail(email)); }
        else
        { throw new ArgumentException(); }
    }

    public bool DoesEmailExistInDatabase(string email) { //code if exists.. }
}

и слой пользовательского интерфейса / Codebehind:

Получить человека по электронной почте 

string emailInput = EmailTextBox.Text;

PersonService pService = new PersonService();
Person p = new Person();

if(p.IsValidEmail(emailInput))
{
    Person myPerson = pService.GetPersonByEmail(emailInput);
}
else
{
    //give user error here...
}

  1. Правильно ли создавать отдельные методы проверки для каждого свойства в доменном объекте, которое может нуждаться в проверке?

  2. Должны ли эти методы в объекте и службе домена быть статическими, чтобы мне не приходилось создавать экземпляр лица только для проверки?

  3. Должен ли я предоставлять проверки из объекта домена Person в Сервисе, чтобы пользователю не нужно было знать, где их искать (поскольку причина, по которой я ввел некоторые в службу, а некоторые в POCO, вопрос реализации)?

4. Есть ли лучший способ?

Ответы [ 2 ]

2 голосов
/ 27 мая 2011

Re # 1 - Да (это правильный подход) при условии, что объект домена лучше всего «знать», каков правильный ввод.

Re # 2 - Да.

Re # 3 - Тем не менее, не причиняя вреда, если вы не доверяете чему-то внешнему по отношению к классу, чтобы быть способным / ответственным за фактическую проверку, почему вы тогда доверяете ему вызывать проверку?

Я бы проверил валидацию, когда значения установлены, когда у вас есть «хорошие данные» в объекте, нет необходимости проверять их позже.Это приводит к пункту № 4 ...

Re # 4 - бонус в том, чтобы как-то предоставлять / показывать подтверждение, состоит в том, что другие части системы могут использовать его;классический пример - это пользовательский интерфейс, где вы можете обеспечить лучший пользовательский опыт, проверяя ввод при его вводе или отправке.

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

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

«Уловка» в этом подходе состоит в том, чтобы быть осторожным в том, как вы называете методы валидации, - не будьте слишком расплывчатыми или двусмысленными.Например, вы можете найти случаи, когда большинство объектов вашего домена, которые имеют свойство электронной почты, используют один «основной» метод проверки электронной почты ValidateGenericEmail(), но вы часто будете иметь случаи, когда другие объекты представляют собой особые случаи со специальными правилами ValidateCorporateEmail().Это нормально, добавьте их в службу проверки, потому что это центральное место на уровне домена для управления этими правилами.

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

0 голосов
/ 27 мая 2011

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

...