Слои приложений и DataMapper - PullRequest
       30

Слои приложений и DataMapper

0 голосов
/ 29 августа 2011

Привет, я только что прочитал книгу «Шаблоны архитектуры корпоративных приложений».Они говорят о том, что вы должны делать корпоративные приложения в слоях, и что вы не должны заставлять один слой использовать вышеперечисленный слой, а только один слой вниз ... Как и в доменном слое, можно использовать слой БД, но не наоборот.Затем есть глава о DataMappers, которые создают доменные объекты.Там меня немного удивляет, почему он может заставить DataMapper на уровне БД создать объект на уровне домена, поскольку он не следует правилу, согласно которому нижний не вызывает верхний.Поэтому мой вопрос не должен быть объектами домена на самом деле на уровне БД, или каков хороший способ сделать объекты домена без использования уровня БД на уровне домена

Ответы [ 3 ]

0 голосов
/ 30 августа 2011

Одним из подходов к решению обнаруженной вами проблемы является использование уровня абстракции между объектами домена и базой данных.

В двух словах это зависимость инверсия / впрыск.

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

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

0 голосов
/ 01 сентября 2011

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

То есть, мы не можем сделать вывод, что он является особенным только для бизнес-уровня. Если вы используете какой-либо компонент ORM, ясно, что Domain-Model используется непосредственно в вашем уровне базы данных, потому что он автоматически сопоставлены внутри.

0 голосов
/ 29 августа 2011

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

Теперь, если вы пойдете по этому пути, я бы сказал, что классы Data Mapper и Domain Model находятся в одном и том же слое, поверх слоя персистентности (который состоит из DAO и сущностей). В этом случае Data Mapper не работает напрямую с базой данных.

Если, с другой стороны, модель предметной области основана на сущностях, то я бы сказал, что она также является частью персистентного уровня, и Data Mapper также выполняет роль DAO в этом случае, поэтому, опять же, они оба (хотя бы частично) в одном слое.

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

...