Синглтон, антипаттерн и все-все-все

[Вурдалак]

hell0w0rd, ты никогда не задумывался почему модель называется моделью, а не «data layer» или как-то там ещё?

http://ru.wiktionary.org/wiki/модель
«что-либо, служащее образцом для чего-либо»

Каждое бизнес-приложение связано с какой-то предметной областью (хотя может быть и с несколькими): знакомства, библиотека, интернет-магазин, etc. Чтобы удовлетворять требования бизнеса, требуется смаппить объекты предметной области на код, смоделировать их. Допустим, модель предметной области рекламной баннерной сети может включать в себя:

• сущности User, Site, Campaign, Banner, ...
• объекты-значения типа BannerType, ...
• сервисы, всякие стратегии типа BannerRotationPolicy

Это всё модель. Да, здесь есть неявные штуки типа BannerRotationPolicy, но тем не менее, политика ротации баннеров скорее всего в такой предметной области есть и нужно это как-то смоделировать в коде, такой класс как раз и является частью модели. Примитивное определение из так называемого MVC, что это «всё, что работает с данными» — это какая-то нелепость. Тем не менее, даже в Википедии написано про модель:

The central component of MVC, the model, captures the application's behavior in terms of its problem domain, independent of the user interface.

Да и вообще, MVC — это какой-то buzzword, каждый понимает как хочет.

Если говорить о слоях, то я признаю такую архитектуру: http://en.wikipedia.org/wiki/Multilayered_architecture — UI, application, domain model, infrastructure. Вот твой инстанс репозитория Doctrine — это инфраструктуный уровень. Бизнесу насрать где хранятся объекты, как это работает под капотом. Это не модель.

 

[Вурдалак]

Кстати, многое из того, что я тут написал, так или иначе отражено в так называемом DDD, советую почитать на эту тему Эванса, например. Там и вода есть, но в целом очень занятная штука.
Более-менее практический пример из Symfony можно тут посмотреть: http://williamdurand.fr/2013/08/07/ddd-with-symfony2-folder-structure-and-code-first/
Но в реальности использовать DDD подход с существующими инструментами, к сожалению, трудно.

P.S. Кстати, вот тот случай, когда для репозитория пишется интерфейс, который был в какой-то из претензаций в одном из холиваров, нужен не для как таковой абстракции над хранилищем (в смысле, вероятность смены Doctrine на Propel или MySQL на Postgres крайне низка), сколько для отделения модели от инфраструктурного слоя. Хотя на практике такая фигня тоже может быть полезна, если для определённой сущности MySQL заменить на Redis, например, или там какой-то декоратор для Pinba над репозиторием сделать и т.д.

 

[fixxxer]

http://www.ozon.ru/context/detail/id/5497184/

Я бы не рискнул читать такую литературу в переводе. Слишком высокие требования к уровню переводчика.

 

[Absinthe]

Redjik, Absinthe, вы одно и то же под моделью имеете ввиду?) у доктрины модель - это инстанс репозитория, а у AR - статические методы модели.

Под моделью мы имеем ввиду уровень бизнес-логики.
А вот ты - какую-то фигню. Модель и вовсе может ничего не хранить. К примеру, формы, калькуляторы и т.д.

 

[Redjik]

Ну только не вся бизнес-логика, конечно.
И в данном разрезе, становится логичным впихнуть в контроллер именно instanceof IDbModelService, и с ним уже работать.
IDbModelService, например, знает о подключении к базе... хотя я таким способом никогда не писал =)

yii он же такой yii =)
как и ларавЕль в принципе =))
да и в симфони я модельки сразу в контроллере создавал =)))

хах, сделаю на досуге бложик полностью на DI =)

 

[AmdY]

[URL='http://phpclub.ru/talk/members/redjik.12328/']Redjik, [/URL]чтобы написать на чистом DI, надо писать два бложека. Первый будет бандл с core реализацией, а второй на основе этого бандла должен менять функциональность без вмешательства в ядро, при обновлении ядра новый бложек должен подхватывать и новые фишки ядра и оставлять функционировать старые.

В реальной же жизни все эти подмены для 99% проектов нужны только для тестирования и проще воспользовать runkit или AspectMock, поплёвыя семки на холивары о di, ioc, sl .....

 

[Absinthe]

В реальной же жизни все эти подмены для 99% проектов нужны только для тестирования и проще воспользовать runkit или AspectMock, поплёвыя семки на холивары о di, ioc, sl .....

А еще в реальной жизни остается тот самый 1% проектов. Крупные проекты, на которых работает куда как больше 1% разработчиков.