Доменные Объекты должны быть представлены как Интерфейсы или как Простые объекты?

Question

Доменные Объекты должны быть представлены как Интерфейсы или как Простые объекты?

Пользовательский интерфейс:

public interface IUser
{
    string FirstName { get; set; }
    string LastName { get; set; }
    string Email { get; set; }
    Role Role { get; set; }
}

Пользовательская реализация (Реализованный на уровень доступа к данным LinqToSql):

public class User : IUser
{
    public string FirstName { get; set; }
    public string LastName { get; set; }
    public string Email { get; set; }
    public Role Role { get; set; }
}

Пользовательская реализация (Реализованный на уровень доступа к данным NHibernate):

[NHibernate.Mapping.Attributes.Class]
public class User : IUser
{
    [NHibernate.Mapping.Attributes.Property]
    public string FirstName { get; set; }

    [NHibernate.Mapping.Attributes.Property]
    public string LastName { get; set; }

    [NHibernate.Mapping.Attributes.Property]
    public string Email { get; set; }

    [NHibernate.Mapping.Attributes.Property]
    public Role Role { get; set; }
}

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

31

c# domain-driven-design

задан Yoann. B 28 February 2010 в 21:15

3 ответа

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

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

7

ответ дан 27 November 2019 в 22:39

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

Интерфейс вашего примера не имеет никакого поведения, кроме геттера / сеттера. Интерфейсы не для этого.

1

ответ дан 27 November 2019 в 22:39

Другие вопросы по тегам:

c# domain-driven-design

Похожие вопросы:

score 27 · Accepted Answer

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

Считайте, что модель предметной области - это модель человека. Бизнес / услуга / документ - это буквально домен. Большинство из нас разрабатывают программное обеспечение для одного бизнеса или цели. Если модель предметной области меняется, это происходит из-за того, что изменились бизнес-правила, и, следовательно, старая модель предметной области больше не действует - нет причин оставлять старую, работающую вместе с новой.

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

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

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

Вот некоторые типы объектов, которые вы хотите использовать в качестве интерфейсов:

Репозитории, отвечающие за загрузку / сохранение объектов домена;
Плагины / расширения для вашей программы;
] Модели просмотра / докладчика, чтобы можно было подключать различные пользовательские интерфейсы;
Абстрактные типы данных со многими реализациями (массив, список, словарь, набор записей и таблица данных - все это последовательности AKA IEnumerable );
Абстрактные операции с множеством возможных алгоритмов (сортировка, поиск, сравнение);
Коммуникационные модели (те же операции через TCP / IP, именованные каналы, RS-232);
Все, что зависит от платформы, если вы планируете развернуть более чем на одном (Mac / Windows / * nix).

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

зависят от факторов, которые, вероятно, находятся вне вашего контроля;
Вероятны изменения в будущем; и
являются горизонтальными элементами (используются во многих частях приложения / архитектуры).

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