Шаблоны проектирования: фабрика и хранилище - PullRequest
Новая
       16

Шаблоны проектирования: фабрика и хранилище

5 голосов
/ 29 октября 2009

Мне было интересно, если Factory Pattern и Repository Pattern намерены идти рука об руку в проекте доменного дизайна?

Причина, по которой я спрашиваю, заключается в том, как я это делаю, так:

GUI -> ClassFactory -> ClassProduct (в модели предметной области) -> ClassProductRepository -> Источник данных

GUI вызывает ClassFactory для отделения GUI от бизнес-логики. ClassProduct вызывает ClassProductRepository для отделения бизнес-логики от источника данных.

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

Ответы [ 2 ]

8 голосов
/ 29 октября 2009

Вы на правильном пути. Как отметил Чад, вы захотите использовать шаблон разделения интерфейса GUI в качестве дополнительного слоя между вашим доменом и пользовательским интерфейсом. MVC, MVP, Presentation Model и т. Д. Представляют собой хорошо документированные шаблоны для разделения пользовательского интерфейса. Превосходное PoEAA Мартина Фаулера охватывает многие из них

Что касается вашего основного вопроса. Да. Фабрики и хранилища работают очень хорошо вместе. Фактически, Эванс в DDD предлагает, что в некоторых случаях вы можете делегировать ответственность за создание объектов из вашего хранилища на ваши фабричные классы, когда вы восстанавливаете объекты из хранилища данных. 

client <=> repository -> factory
               |
               v
            database
  1. Клиент запрашивает объект у хранилище.
  2. Хранилище запрашивает базу данных.
  3. Хранилище отправляет необработанные данные в завод.
  4. Фабрика возвращает объект.

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

1 голос
/ 29 октября 2009

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

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

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

...