Вопрос по архитектуре (навеяно livestreet)

[Духовность™]

Вопрос по архитектуре (навеяно livestreet)

Посмотрел я livestreet. На удивление код оказался легкочитаемым, в отличие от.... короче, на редкость приятно читать код.

Там модель - это три сущности. На примере модуля User:

- ModuleUser - класс с логикой определенной модели. http://trac.lsdev.ru/svn/livestreet/trunk/classes/modules/user/User.class.php
- ModuleUser_EntityUser - объект-хранилище сущности. http://trac.lsdev.ru/svn/livestreet/trunk/classes/modules/user/entity/User.entity.class.php
- ModuleUser_MapperUser - маппер для работы с БД. http://trac.lsdev.ru/svn/livestreet/trunk/classes/modules/user/mapper/User.mapper.class.php

Так вот, меня всегда интересовало, куда девать повторяющуюся логику в контроллерах. В livestreet это все засовывается в ModuleUser и вызывается в контроллерах примерно так:

$oUser=$this->User_Action()

соответственно вызывается метод Action() класса User. Вполне, как мне кажется, хорошее решение.

Вопрос у меня в следующем - как и куда ещё можно выносить логику модели? Как вы обычно это делаете?

И насколько вам кажется правильным/не правильным иметь один общий класс, объединяющей entity и ModuleUser?

 

[soines]

Мне кажется, что в одном классе хранить их не стоит, т.к. сущность может быть одна, а вот "модулей" работающих с ними несколько.

 

[Духовность™]

up!

 

[zerkms]

Для тех, кто не ковырял ливстрит текст треда совсем непонятный (по крайней мере мне)

Если я правильно догадываюсь - тогда нормально, что у тебя сервисная логика сосредоточена в отдельных классах. Как группировать эту логику - никаких правил нет. Группируй согласно природе бизнес-логики, которая внутри. Часто у тебя естественным образом эта группировка будет совпадать с "группировкой по сущности".

 

[korchasa]

zerkms
Entity - DTO
Module - Service
Вполне стандартно. Осталось еще DAO выделить

В примерах бардак. Что делает createSession в mapper'е? С какого перепугу GetUserBySessionKey($sKey) возвращает id?