Как правильно создать домен с помощью Zend Framework?

Question

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

Я использую Zend Framework, который реализует шаблоны шлюза табличных данных и шлюза строк данных для уровня доступа к данным, но, по-видимому, не может действительно определить, как построить уровень домена, который отделен от уровня доступа к данным. Я рассмотрел использование шаблона Active Record, в котором логика домена сосуществует с логикой доступа к данным, но у меня есть следующая ситуация, которая возникает хотя бы раз, и я не думаю, что Active Record будет обрабатывать:

У меня есть одна таблица "Person", которая содержит поля person_id и userType.

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

Я не хочу раздувать объект Row Data Gateway с бизнес-логикой, которая принадлежит только одному типу пользователей, но я не уверен, как построить уровень домена для представления разных типов пользователей. Например, я могу создать объект Person, который содержит объект PersonGateway, а затем написать функции-оболочки, которые передают вызовы к объекту шлюза, или я пишу объект Person для расширения объекта PersonGateway, а затем реализую только конкретные функции, которые мне нужны?

Аналогично, я обычно думаю, что это (частично) фабричная проблема, когда мне нужен фабричный метод, который будет создавать правильный подкласс на основе userType. Это все еще лучший метод с классом Zend Framework Zend_Db?

Будем весьма благодарны за любые предложения или ссылки на учебные пособия, в которых рассказывается о том, как правильно создать модель домена поверх Zend_Db.

Answer 1

Доменные модели ничего не расширяют. Это просто классы, которые вы используете для инкапсуляции бизнес-логики. Они могут использовать объекты доступа к данным, поэтому в классе может быть protected экземпляр объекта-шлюза данных строки. Объект Row обычно представляет экземпляр домена ближе, чем объект Table. Кроме того, вы всегда можете получить объект Table с помощью метода Row s getTable().

Обычно классы 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/