Я задал этот вопрос некоторое время назад, но теперь я ищу, чтобы реализовать фактическое разделение между моим уровнем доступа к базе данных и уровнем домена. Я также собираюсь работать над перемещением бизнес-логики в домен, где он принадлежит, и из сценариев контроллера.
Я использую Zend Framework, который реализует шаблоны данных Data Gateway и Row Data Gateway для уровня доступа к данным, но, по-видимому, он действительно не может определить, как создать слой домена, который отделен от уровня доступа к данным. Я рассмотрел использование шаблона Active Record, где логика домена сосуществует с логикой доступа к данным, но у меня есть следующая ситуация, которая происходит хотя бы один раз, когда я не думаю, что Active Record будет обрабатывать:
У меня есть отдельная таблица «Лицо», которая содержит поля person_id и userType.
Каждый пользовательский тип (администратор, покупатель, помощник, супервизор) имеет связанную с ним специфическую бизнес-логику, и все типы наследуют некоторые базовые функции от объекта Person.
Я не хочу раздувать объект Row Data Gateway бизнес-логикой, которая относится только к одному типу пользователей, но я не уверен, как создать слой домена для представления различных типов пользователей. Например, создать объект Person, который содержит объект PersonGateway, а затем написать функции-обертки, которые передают вызовы объекту шлюза, или написать объект Person для расширения объекта PersonGateway, а затем реализовать только те конкретные функции, которые мне нужны?
Аналогично, я обычно думаю, что это (частично) фабричная проблема, когда мне нужен фабричный метод, который будет создавать правильный подкласс на основе userType. Это лучший метод для Zend Framework?
Любые предложения или ссылки на учебные пособия, которые рассказывают о том, как правильно создать модель домена поверх Zend_Db, будут с благодарностью оценены.
Модели доменов не распространяются. Это просто классы, которые вы используете для инкапсуляции бизнес-логики. Они могут использовать объекты доступа к данным, поэтому внутри класса может быть protected экземпляр объекта шлюза данных строки. Объект Row обычно представляет экземпляр домена более тесно, чем объект Table . Кроме того, вы всегда можете получить объект Table с помощью метода getTable() Row .
Обычно классы DM имеют интерфейс с методами, соответствующими операциям более высокого уровня, которые вы можете выполнять с этим классом. Но вы не обязательно должны обрабатывать все операции доступа к данным.
class Person { // Zend_Db_Table_Row object protected $data; public function subscribeToService(Service $service) { ... } public function sendMailTo(Person $recipient) { ... } public function changePassword($newPassword) { ... } }
Я также писал об этой теме прошлой весной и недавно написал об этом в списке рассылки ZF.
Что касается учебников и ресурсов, попробуйте http://domaindrivendesign.org/