Создание объекта Fowler Data Mapper

Question

Я использовал шаблоны Фаулера для доменных моделей с Data Mapper и столкнулся с некоторой путаницей в том, как реализовать часть CRUD для создания. Я не могу использовать существующие технологии ORM, поскольку основными источниками данных являются пользовательские системы. Меня беспокоит то, как вызывать нижележащую ORM, когда мне нужно создать новый объект. Мой уровень домена не отображает мою ORM, за исключением моих искателей.

Я не уверен, что нахожусь на правильном пути, но я вижу только следующие варианты:

1. Обрабатывайте функции создания так же, как и средства поиска Фаулера. Создайте интерфейс на уровне модели домена для методов создания в классах ORM. Затем пусть модель домена вызовет контейнер DI и создаст экземпляр экземпляра класса ORM на основе интерфейса.

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

3. ???

Я, должно быть, что-то упустил, поскольку это не может быть таким сложным. Любая помощь будет высоко ценится.

Спасибо

Answer 1

Как насчет того, как ORM решают эту проблему? На языках, которые поддерживают динамическое создание объектов, «отображение» того, как данные связаны с объектами домена, предоставляется в виде отдельной конфигурации. Классы создаются с помощью отражения или библиотеки байт-кода. Я полагаю, это зависит от того, насколько вы хотите сделать Data Mapper. Из того, что я могу почерпнуть из оригинального паттерна, картографы данных могут существовать для каждого предметного объекта.

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

То есть сегодня слой ORM может работать со строками, представляющими имя CanonicalClass + список методов, ожидаемых для этих классов.

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

Answer 2

Если ваша проблема заключается в отображении типа A в тип B, вы можете рассмотреть AutoMapper .

Answer 3

Если вы внедряете в .NET, как предложил Ричард, посмотрите AutoMapper . Если вы внедряете в Java, посмотрите ModelMapper .

Answer 4

Re: «Как вызвать базовый ORM, когда мне нужно создать новый объект»

Рассматривали ли вы идею AGGREGATE ROOT и шаблоны хранилища - они могут быть полезны.

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

FACTORIES для AGGREGATE ROOT также обычно инициализируются на знать о слоях данных при запуске приложения / начальной загрузке.

В этом случае хранилище может оперировать процессом сбора данных для объекта любым удобным для него способом. REPOSITORY делегирует слой данных / маппер для получения необработанных данных и имеет тенденцию делегировать фактическую работу восстановления объекта FACTORY (класс / метод) для создания здания. Затем REPOSITORY возвращает вновь восстановленный объект AGGREGATE ROOT или of) клиенту, который вызвал метод поиска хранилища - то есть приложение. Хранилище является интерфейсом для извлечения и сохранения AGGREGATE ROOT и дает представление о том, как они хранятся в памяти.

Приложение может напрямую использовать FACTORY для создания нового объекта AGGREGATE ROOT.

Фабрика AGGREGATE ROOT обладает хорошими знаниями о слоях ORM / Mapper, и при создании совершенно новой сущности она может обратиться к услугам какого-то «объекта последовательности чисел», чтобы получить свой уникальный идентификатор.

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

• объекты одноразовой стоимости - как денежная стоимость, ИЛИ
• Объекты, зависящие от AGGREGATE ROOT. То есть объекты, имеющие идентификаторы, которые являются уникальными только в контексте AGGREGATE ROOT, что подразумевает, что
  • AGGREGATE ROOT действительно должна быть единственной вещью, которая должна найти его / использовать - внутренне
  • их можно найти с помощью ORM Mapper AGGREGATE ROOT
  • их идентификаторы могут быть созданы AGGREGATE ROOT, который определяет его контекст / область действия

Дополнительная литература:

См. Проект, управляемый доменом, Эрик Эванс.

Совокупный корень: http://books.google.co.uk/books?id=7dlaMs0SECsC&lpg=PP1&dq=domain%20driven%20design&pg=PA147#v=onepage&q=&f=false

Repositroies: http://books.google.co.uk/books?id=7dlaMs0SECsC&lpg=PP1&dq=domain%20driven%20design&pg=PA147#v=onepage&q=&f=false