2016-01-05 8 views
0

Согласно этой статье hereЯ правильно использую объект домена?

Вы можете думать о них [Услуги] как «объекты домена высшего уровня», но вместо того, чтобы бизнес-логики, службы несут ответственность за взаимодействие между объектами домена и Картостроители. Эти структуры в конечном итоге создают «открытый» интерфейс для взаимодействия с бизнес-логикой домена. Вы можете избежать их, но в ущерб утечке некоторой логики домена в контроллеры.

Я читал на MVC, а Ive разбил M-часть на Службы, объекты домена и Data Mappers. Службы и карты данных легко понять, но я не понимаю причину для объектов домена, можете ли вы привести несколько примеров? Вот мой код:

MemberService

class MemberService extends Service 
{ 
    public function authenticate() 
    { 
     $domainObject = $this->domainObjectFactory->getDomainObject('Member'); 
     $dataMapper = $this->databaseFactory->getMapper('Member'); 

     $_temp_sess_id = 0; 
     $_temp_sess_password = ""; 

     $member = $dataMapper->fetch($_temp_sess_id); 
     $authenticationResult = $domainObject->checkPassword($member['password'], $_temp_sess_password); 

     if (!$authenticationResult) 
     { 
      $member = ['user_id' => 0]; 
     } 

     return $member; 
    } 
} 

MemberDomainObject

class MemberDomainObject extends DomainObject 
{ 
    public function checkPassword($dataMapperPassword, $locallyStoredPassword) 
    { 
     if ($dataMapperPassword !== $locallyStoredPassword) 
      return false; 
     return true; 
    } 
}  

UPDATE:

Этот вопрос касается метода checkPassword и почему его необходимо создать отдельный объект просто использовать оператор IF, который может быть использован внутри службы, вместо этого сохраняя ОЗУ с использованием дополнительных ресурсов для создания нового объекта.

+0

Возможная Дубликат [Понимание объектов домена/службы] (HTTP://stackoverflow.com/questions/5589141/understanding-domain-objects-services) – Reloecc

+0

в порядке, в нем говорится: «Объектами домена являются данные, а службы домена - это часть do-stuff-with-the-data». Так что я должен сделать все, если в разделе службы, а есть $ member, хранящийся в DO? –

+0

также, в соответствии с этим ответом здесь: http://stackoverflow.com/questions/5863870/how-should-a-model-be-structured-in-mvc?lq=1, «Вы можете думать о них [Услуги] как «Объекты домена более высокого уровня», но вместо бизнес-логики Сервисы несут ответственность за взаимодействие между объектами домена и Mappers ». –

ответ

0

Вы только что создали объект MemberDomainObject через какой-либо завод в своем примере. Код, который вы показываете, не имеет нулевой информационной ценности для этой цели.

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

Вас не интересует только «объекты модели»? Не нужно говорить о объектах домена, если вам нужно быть уверенным в правильности отношения «service> factory> model object> mapper».

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

один совет: имена использование класса с пространствами имен (FQN) в ваших заводах, это поможет вам с навигацией корыто кода и рефакторинга, а

$member = $this->domainObjectFactory->getDomainObject(MemberDomainObject::class); //in php5.5+ 

вы можете заменить с

class DomainObject 
{ 

    static function className(){ 
     return get_called_class(); 
    } 
} 

$member = $this->domainObjectFactory->getDomainObject(MemberDomainObject::className()); 

в php < = 5.4 и заменить его при обновлении.

так же, как и

$member = $this->domainObjectFactory->getMember(); 

не является проблемой, так как вы можете указать тип возвращающегося в :: getMember()

+0

Я не могу выделить пространства имен. Кроме того, вы правы в том, что вы написали, но он не отвечает на мой вопрос. Мой вопрос: зачем нужны объекты домена? Если вы посмотрите на эту строку: $ authenticationResult = $ domainObject-> checkPassword ($ member ['password'], $ _temp_sess_password); Это может быть заменено простым оператором IF, который устранит необходимость использования ресурсов ОЗУ для создания нового объекта. –

+0

, тогда измените свой вопрос на что-то вроде «почему сохранить модельную логику в модели, а не в контроллере», если вы заинтересованы в ... – Reloecc

+0

То, как я спросил, является абсолютно верным помощником. –

 Смежные вопросы

  • Нет связанных вопросов^_^