Инкапсуляция общей логики (доменный дизайн, передовая практика)

Question

Обновлено: 09/02/2009 - Пересмотренный вопрос, при условии лучшего примера, добавлен баунти.

---

Привет,
Я строй PHP приложения с использованием шаблона сопоставителя данных между базой данных и объектами (объекты домена). Мой вопрос:

Каков наилучший способ инкапсуляции обычно выполняемой задачи?

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

$siteMapper = new Site_Mapper(); 
$site = $siteMapper->findByid(1); 

$pageMapper = new Page_Mapper(); 
$site->addPage($pageMapper->findHome($site->getId())); 

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

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

$someObject = new SomeClass(); 
$site = $someObject->someMethod(1); // or 
$sites = $someObject->someOtherMethod(); 

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

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

$siteMapper->save($site); 
$pageMapper->save($site->getHomePage()); 

Опять же, тривиально, но этот пример упрощен. По-прежнему применяется дублирование кода.

На мой взгляд, это имеет смысл, чтобы иметь какой-то центральный объект, который может позаботиться о:

• Извлечение сайт (или сайты) и все nessessary ассоциированными сущностями
• Создание новых объектов сайта с помощью нового связанные с ней организации
• Принимая сайт (или сайты) и сохранение его и все связанные с ним объекты (если они изменились)

Итак, вернемся к моему вопросу, что должно быть этот объект ?

• Существующий объект карты?
• что-то на основе репозитория шаблона? *
• что-то на основе единицы работы Паттен? *
• Что-то еще?

* Я не полностью понимаю любой из них, как вы, вероятно, можете догадаться.

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

Спасибо,
Джек

Answer 1

Использование шаблона хранилища/службы, ваши Repository классы будут предоставлять простой интерфейс CRUD для каждого из субъектов, то классы обслуживания будут представлять собой дополнительный слой, который выполняет дополнительную логику, как прикрепление зависимости сущностей. Остальная часть вашего приложения использует только Службы. Ваш пример может выглядеть следующим образом:

$site = $siteService->getSiteById(1); // or 
$sites = $siteService->getAllSites(); 

Тогда внутри класса SiteService вы бы что-то вроде этого:

function getSiteById($id) { 
    $site = $siteRepository->getSiteById($id); 
    foreach ($pageRepository->getPagesBySiteId($site->id) as $page) 
    { 
    $site->pages[] = $page; 
    } 
    return $site; 
} 

Я не знаю PHP, что хорошо, поэтому, пожалуйста, извините, если что-то неправильно синтаксически ,

Answer 2

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

Что бы вы назвали этим методом? Обычно это имя указывает, к чему относится метод.

Answer 3

[Edit:. Эта запись делается попытка рассмотреть тот факт, что это часто проще писать собственный код непосредственно иметь дело с ситуацией, чем пытаться вписаться проблему в шаблон]

Patterns хороши в концепции, но они не всегда «на карте». После многих лет разработки PHP на высоком конце мы решили очень прямо обращаться с такими вопросами. Рассмотрим это:

Файл: Site.php

class Site 
{ 
    public static function Select($ID) 
    { 
     //Ensure current user has access to ID 
     //Lookup and return data 
    } 

    public static function Insert($aData) 
    { 
     //Validate $aData 
     //In the event of errors, raise a ValidationError($ErrorList) 

     //Do whatever it is you are doing 

     //Return new ID 
    } 

    public static function Update($ID, $aData) 
    { 
     //Validate $aData 
     //In the event of errors, raise a ValidationError($ErrorList) 

     //Update necessary fields 
    } 

Тогда для того, чтобы вызвать его (в любом месте), просто запустите:

$aData = Site::Select(123); 

Site::Update(123, array('FirstName' => 'New First Name')); 

$ID = Site::Insert(array(...)) 

Одна вещь, чтобы иметь в виду о программировании OO и PHP ... PHP не поддерживает «состояние» между запросами, поэтому создание экземпляра объекта только для его немедленного уничтожения нередко имеет смысл.

Answer 4

class Page { 

    public $id, $title, $url; 

    public function __construct($id=false) { 
    $this->id = $id; 
    } 

    public function save() { 
    // ... 
    } 

} 

class Site { 

    public $id = ''; 
    public $pages = array(); 

    function __construct($id) { 
    $this->id = $id; 
    foreach ($this->getPages() as $page_id) { 
     $this->pages[] = new Page($page_id); 
    } 
    } 

    private function getPages() { 
    // ... 
    } 

    public function addPage($url) { 
    $page = ($this->pages[] = new Page()); 
    $page->url = $url; 
    return $page; 
    } 

    public function save() { 
    foreach ($this->pages as $page) { 
     $page->save(); 
    } 
    // .. 
    } 

} 

$site = new Site($id); 
$page = $site->addPage('/'); 
$page->title = 'Home'; 
$site->save(); 

Answer 5

Сделайте свой сайт объектом Aggregate Root, чтобы инкапсулировать сложную ассоциацию и обеспечить согласованность.

Затем создайте SiteRepository, который несет ответственность за получение агрегата Сайта и заполнение его дочерних элементов (включая все страницы).

Вам не понадобится отдельный PageRepository (при условии, что вы не делаете страницу отдельным сводным корнем), и ваш SiteRepository должен также нести ответственность за объекты страницы (в вашем случае с помощью существующих Mappers) ,

Итак:

$siteRepository = new SiteRepository($myDbConfig); 
$site = $siteRepository->findById(1); // will have Page children attached 

И тогда метод findById будет нести ответственность за все также найти страницу детей Сайта.Это будет иметь сходную структуру с ответом, предоставленным CodeMonkey1, однако я полагаю, что вы выиграете больше, используя шаблоны Aggregate и Repository, вместо того, чтобы создавать определенный сервис для этой задачи. Любое другое извлечение/запрос/обновление агрегирования Сайта, включая любой из его дочерних объектов, будет осуществляться через один и тот же SiteRepository.

Редактировать: Here's a short DDD Guide, чтобы помочь вам с терминологией, хотя я бы действительно рекомендовал прочитать Evans, если вы хотите получить полную картину.