Загрязнение типов доменов путем реализации интерфейсов, связанных с инфраструктурой

Question

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

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

Однако я нахожусь в состоянии, когда я не уверен, как обойти это. В частности, у меня есть тип домена, который идеально подходит для использования на моем уровне представления, за исключением того, что я хотел бы отобразить его экземпляр в элементе управления, который требует реализации IComparable. Я бы не стал «загрязнять» мой тип реализацией этого интерфейса.

Я думаю (возможно, наивно), мои варианты:

1. Используйте объект передачи данных (DTO), сделайте так, чтобы он реализовал интерфейс, и используйте экземпляр этого в моем слой представления.
2. Я смутно знакомы с основами АОП - возможно, есть подходящий техника в этом мире?
3. Возможно связано с вариантом 2 - код «ткачество»? Я очень мало знаю, почему / когда рассмотреть это, но я столкнулся против этого сейчас?
4. Укуси пулю, и реализовать немного кода что требуется для удовлетворения контракта.
5. Некоторая магия вуду никогда даже не слышал?

Если кто-нибудь захочет порекомендовать 2, 3 или 5 - не могли бы вы указать мне какой-нибудь материал для чтения, который может помочь мне начать?

Спасибо заранее.

Answer 1

реализовать промежуточный класс "View-Model":

• Часть View знает, как общаться с пользовательским интерфейсом (привязка данных, IComparable и др.)
• содержит ссылку на объект Модель (домен)
• предоставляет свойства объекта Model (и при необходимости ретранслирует уведомления об изменении)

Answer 2

1. Это будет работать, и должно быть хорошо.

2-4. Это действительно один и тот же вариант. Разница в как вы реализуете код для удовлетворения контракта. Переплетение кода и AOP все еще «загрязняют» ваш объект, но они выполняют работу за вас полуавтоматическим способом (то есть: вы просто помещаете атрибут в ваш объект, и он реализует его после компиляции). Окончательный результат остается тем же, независимо от того, реализуете ли вы объект или используете AOP / code gen.

5. Мое предложение ниже:

В большинстве случаев все, что требует IComparable<T>, также предоставляет возможность передать IComparer<T>. Если ваш элемент управления это сделает, это позволит вам реализовать логику сравнения, внешнюю по отношению к вашим объектам данных, и просто передать ее. Сначала я бы изучил это как вариант.

В противном случае, я бы предложил просто реализовать IComparable<T> непосредственно в объекте. Если вы не хотите «загрязнять» API, просто реализуйте его явно.