Блог

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

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

 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) amp;amp; 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) amp;amp; p.IsValidName(p.Name) amp;amp; !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. Должны ли эти методы в объекте домена и службе быть статическими, чтобы мне не приходилось создавать экземпляр person только для выполнения проверки?

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

4.Is есть способ получше?

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

Повторный # 2 — Да.

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

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

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

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

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

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

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

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