Спасибо за уточнение, не сталкивался с Yii, посмотрел, у них пожалуй самые развитые блоки (виджеты) из подобных, но насколько я понял это не самостоятельное решение, и отличается по функционалу с пакетом, по-этому желающие (например я) не смогут использовать это как альтернативу.
Yii3 будет модульный, посмотрите возможно уже данный блок есть отдельно.
Это суффиксы, чтобы отметить Controller-ы для автозагрузки, модель Article, а контроллер ArticleC. Использовать 'Controller' целиком как суффикс было бы слишком многословно при большом количестве блоков.
У вас есть пространство имен, и данные суффиксы не имеют смысла. А если уж и делать суффиксы, то полностью т.к. «C» — это очень неоднозначно (может это Controller, а можно это просто Class (по аналогии с I и T), или Classificier и т.д.
С некоторыми шаблонами «конкурентов» знаком, как WordPress, Symfony, Codeigniter. Также альтернатив, подобных уже существующих пакетов, которые делают то же самое при поиске не нашел.
Yii2 виджеты, Битрикс (прости господи) компоненты.
По факту у вас обычная MVC, хотя в данной ситуации контроллер который просто возвращает модель как таковой не нужен (опять если делать референс в сторону Yii2 термин «виджет» больше подходит, нежеле «контроллер», хотя суть та же самая: модель -> виджет -> вьюха). Могли сократить сущности до модель — вьюха, а сам рендеринг скинуть на какую-то отдельную сущность например Renderer, т.к. для каждой модели не нужен отдельный контроллер.
Если не трудно, хотелось бы пару примеров из кода с альтернативной версией (правильной по вашему)
Прежде чем что-то изобретать, неплохо бы ознакомиться с «конкурентами». Как организована работа с шаблонами и виджетами в фрейморках и других CMS. Ну и уже по традиции комментариев данного топика: нейминг конечно ужасный :)
внедрения зависимостей это инструмент который проставляет необходимые зависимости, главное отличие di от service locator что класс куда проставляются зависимости знать не знает о di и ему без разницы кто передает зависимости какая то библиотека di или созданно в ручную.
Дак собственно createInstance создает объект которые инициируется через конструктор (в коде пример неправильный, исправил). Реализацию контейнера я посчитал добавлять сюда лишнее, потому что речь не про DI.
но если обратить внимание код в примерах не рабочий у NotifyAuthorAboutComment есть метод setPost, но он например нигде не вызывается :)
Вызывается в методе addComment — это было и до исправлений :)
смысл от этого интерфейса репозитория? который зависит от конкретной модели?
чтобы сделать мок? мокать можно и классы внезапно phpunit.readthedocs.io/en/9.0/test-doubles.html
Зачем в итоге этот интерфейс репозитория?
Интерфейс репозитория — для разных реализаций репозитория, а не разных реализаций поста. Никто не мешает наследоваться от КЛАССА внезапно!
Нет, не aka. Репозитории (опять же, по Фаулеру, я не знаю, что вы под этим понимаете) привязаны к бизнес-сущностям, а не к таблицам.
Да, согласен.
Кстати, отсюда же проистекает и ваше непонимание, что делать с Condition — описывать его в терминах домена, как и полагается Query Object (снова Фаулер). Да, придется мапить. Но репозитории неизбежно предполагают маппинг, вы никуда от этого не денетесь.
И это по вашему правильно и удобно? В теории может все и красиво, но если мы говорим про практику, то на дальную перспективу отдельные методы куда удобнее.
Тут речь не в понимании, а в том, что на реальных (а не теоритических в учебнике) проектах, это впоследствии вызывает проблемы
Bad programmers worry about the code. Good programmers worry about data structures and their relationships
А почему вы решили что фраза «беспокоятся о данных и их связях», речь про БД? Бизнес-логика — это данные. Нужно продумывать взаимодействия объектов, то как объекты будут выглядеть и функционировать. А уже ПОТОМ думать о том как они будут хранится.
Потому как если вы начнете с определения БД и уже далее будете от этого отталкиваться, то это наложит свой отпечаток на реализации. А если вы сначала реализуете логику работы, то как сущности будут между собой взаимодействовать, то может вообще увидите, что вам лучше использовать документоориентированную БД вместо реляционной.
P.S. уверен есть и маститые парни которые которые за code-first подход :)
Потому что вы начинаете с захода «сейчас я объясню, что такое модель», потом пишете «самое правильное определение для модели», а потом выясняется, что это просто вы подразумеваете под моделью.
А почему «пишу самое правильное определение» это не тождественно равно «подразумеваю под моделью»? Синонимы как по мне.
Дело не в референсе, а в том, что вы подаете свое мнение как «самое правильное».
Дак а я не увидел опровержений. Модель — это все что касается бизнес-логики. У Фаулера (с ваших слов) Модель — это все что не UI. Чем мое определение хуже, чем у Фаулера?
Касаемо DDD — термина модели нет, есть Агрегат, Сущность, VO — что по факту является детализацией/конкретизацией термина «модель»
И опять возвращаемся к терминологии: Post — это агрегат, а Comment — это сущность. Но я в статье не упоминал про данные термины (потому что это очередное усложнение в рамках данной статьи и вообще понятия Модель, которое необходимо лишь для понимания нотации DDD). И даже если говорить про агрегаты, то в любом случае репозиторий агрегата, не должен сохранять/удалять другие сущности/агрегаты, для которых есть собственные репозитории (aka собственные таблицы). Если сущность хранится в той же таблице, что и агрегат, то да, такую сущность репозиторий может обработать. Связи между сущностями (связи M:N через дополнительные таблицы) тоже можно обрабатывать.
Я не знаю, что в «таком» контексте, а в нормальном контексте (у Эванса) в агрегате — несколько сущностей, на то он и агрегат.
Если бы я писал про DDD, я бы изначально ввел ряд терминов для понимания о чем речь. В данной статье использовался термин Модель, с смыслом описанным вначале.
Я как раз и обозначил вначале статьи что подразумевается под моделью. Потому что иначе пришлось бы рядом со словом модель писать пояснения для всех концепций (в рамках MVC — модель, в рамках DM — domain object и т.д.).
Занятное чтиво бы получилось. И наверняка нашелся бы тот (или какая-либо концепция), чье понимание я не отразил. Так что слово «модель» в рамках данной статьи, отражает именно то, что написано в статье.
Никогда бы не подумал что краткий референс на Domain Model сломает до такой степени понимание.
Как мы славно прыгаем по концепциям и терминам. Я для этого вначале статьи специально написал, что «модель — это бизнес-логика». Видимо чтобы было понятно для вас слово модель везде надо было заменить на «domain object», тогда бы вопросов не возникло?
Причем когда мы говорим про AR, такого вопроса почему то не возникает, и по-умолчанию понятно что является моделью. Хм…
Ох, чувствую надо сначала определить термины, чтобы мы на одном языке разговаривали:
Агрегат (Aggregate) – самостоятельный объект, имеющий идентичность.
Сущность (Entity) – несамостоятельный объект, имеющий идентичность.
Значение (Value Object) – несамостоятельный объект, не имеющий идентичности.
Про эти агрегаты речь? Если да, то определим, что моя концепция не разделяет эти 3 сущности и все 3 является моделями. Собственно при ТАКОМ контексте, в чем проблема?
Дак база все это и может делать, я же говорю положить болт на БД, а говорю что она ВТОРИЧНА, а логика ПЕРВИЧНА. Ну и собственно контроллеры не должны обрабатывать бизнес-логику, а должны делегировать это моделям (которые отражаются сущности предметной области), а Mapper'ы это уже слой данных.
Выше (в другой ветке) уже писали, что в концепции MVC, модель — это все что не касается интерфейса. Поэтому по факту M включается в себя слой данных и домена, а C — представляет из себя слой приложения. И где-то рядом еще сервисный слой должен лежать.
Не нужно ограничивать себя рамками MVC и считать, что модель — это база (повторюсь, это неверно).
Тогда в чем смысл вопроса «все ли до конца понимают, что эти слова означают?». Мы вот выяснили, что вы — не понимаете.
Мы вроде выяснили что я понимаю не так как Вы, а ваша аргументация почему мое понимание не ложится в концепцию DM слабо выглядит.
Определение Фаулера (краткое):
A Domain Model creates a web of interconnected objects, where each object represents some meaningful individual, whether as large as a corporation or as small as a single line on an order form.
Объекты отражающие сущности бизнес-логики (о чем в статье и речь). Если вы это определение воспринимаете иначе, то это уже проблема восприятия, а не формулировок.
Эээ чуть выше вы сами написали что в разных концепциях термин «модель» имеет разные значения (MVC и DM). Поэтому мое мнение НЕ не правильное, а отличающееся от концепции MVC и ложащееся в концепцию DM (domain objects).
Я и не провозглашал, что мое мнение истина в последней инстанции. Я лишь сказал что модели — это исключительно бизнес-логика. И это мнение правильное для меня, и абсолютно не ложится в термины MVC. Я эту идею транслирую, так же как Фаулер транслирует свою. Это разные точки зрения (да и по большому счету «о разном») и как-то сравнивать 2 термина из разных концепций странное занятия (естественно у Фаулера запас доверия куда бооооооольше, но это не значит что мое мнение ничего не стоит).
Ну собственно когда я говорю модель — я имею ввиду domain object. А Domain Model — это по сути концепция/подход, а не сущность/объект. Вроде в этом ключе все и описано в статье, но в любом случае пройдусь еще раз, чтобы не было недопонимания. Спасибо!
Нет, это вы так придумали. Но ни в понятии Domain Model, ни в понятии MVC слово Model это не обозначает.
Окей, разберемся в терминах. Чуть выше я привел пример объект «деньги», который по моему мнению тоже модель (без поведения, просто данные). Вы говорите что это не модель, а объект домена — все верно?
Т.е. модели — это то что отражает объекты предметной области (неважно есть поведение или нет), а объекты домена — это вспомогательные сущности без поведения предметной области?
Повторюсь что это не правильная точка зрения. В формулировке:
весь Ваш бек-енд — это всего-лишь буковка С в аббревиатуре MVC, а моделью в этом случае выступает база
Вы делаете Модель «тупым» хранилищем с которым проводит какие-то операции Контроллер. Таким образом вы раздуваете контроллеры и даете им слишком много ответственности. Перемешиваете слои домена, сервиса и приложения, ну и т.д. Такой проект в последствии будет проблематично расширять и поддерживать.
В данном случае я думаю стоит быть категоричным, т.к. тут нет «относительности». Большой контроллер с массой ответственности — плохо при любом раскладе.
Это конечно замечательно, что вы столько выдержек из теории выдали (спасибо, правда), НО из этих выдержек абсолютно не следует, что представление модели изложенное в статьи противоречит этим определениям.
Мораль: не читайте то, что написано на заборе, читайте первоисточники.
Да, каюсь, некорректно привел информацию о модели в парадигме MVC, но речь в статье НЕ заключалась в объяснении MVC, а рассмотрение конкретного примера работы с моделями.
Из ложной посылки можно сделать любые выводы, но какая в них ценность?
А в чем тут ложность? Вы сами приводите сноску о том, что модель — это объект предоставляющий информацию о домене. По вашему домен != бизнес-логика?
Создается ощущение, что вы решили, что (в Domain Model) модель и сущность — это одно и то же. Так вот, нет:
А что в вашей сноске подтверждает ваше утверждение? Модель и сущность — это термины означающие одно и то же: объект предметной области обладающей поведением и данными данной предметной области. Если вы имеете ввиду различные вспомогательные ValueObject и определяете их как сущности — это опять вопрос терминологии. Даже если мы возьмем такой пример VO как «деньги», то это тоже модель, но без поведения как такового.
Объектная модель домена. То есть, внезапно, слово «модель» относится к целому, а не к его частям. Вот подтверждающая цитата, где модель и составляющие ее объекты противопоставляются:
Вообще не подтверждающая цитата. Здесь лишь говорить о том что модели могут раздуваться до огромных размеров, но это уже вопросы проектирования и реализации, а не подхода как такового. В статье идет разделение на «целое и часть» в рамках конкретной сущности бизнес-логики (например «пост — комментарий»).
То есть допустим, если у нас есть объект «Департамент», который действительно может быть большим, НО большой объект != сложный объект. Если декомпозировать эту модель на его «части» и логику реализовать с помощью бизнес-операций (пример реализации в статье), то объект будет просто большим, но ничуть не сложным.
Yii3 будет модульный, посмотрите возможно уже данный блок есть отдельно.
У вас есть пространство имен, и данные суффиксы не имеют смысла. А если уж и делать суффиксы, то полностью т.к. «C» — это очень неоднозначно (может это Controller, а можно это просто Class (по аналогии с I и T), или Classificier и т.д.
Yii2 виджеты, Битрикс (прости господи) компоненты.
По факту у вас обычная MVC, хотя в данной ситуации контроллер который просто возвращает модель как таковой не нужен (опять если делать референс в сторону Yii2 термин «виджет» больше подходит, нежеле «контроллер», хотя суть та же самая: модель -> виджет -> вьюха). Могли сократить сущности до модель — вьюха, а сам рендеринг скинуть на какую-то отдельную сущность например Renderer, т.к. для каждой модели не нужен отдельный контроллер.
ArticleC и HeaderC это че такое?)))
Дак собственно createInstance создает объект которые инициируется через конструктор (в коде пример неправильный, исправил). Реализацию контейнера я посчитал добавлять сюда лишнее, потому что речь не про DI.
Вызывается в методе addComment — это было и до исправлений :)
Интерфейс репозитория — для разных реализаций репозитория, а не разных реализаций поста. Никто не мешает наследоваться от КЛАССА внезапно!
Да, согласен.
И это по вашему правильно и удобно? В теории может все и красиво, но если мы говорим про практику, то на дальную перспективу отдельные методы куда удобнее.
Тут речь не в понимании, а в том, что на реальных (а не теоритических в учебнике) проектах, это впоследствии вызывает проблемы
А почему вы решили что фраза «беспокоятся о данных и их связях», речь про БД? Бизнес-логика — это данные. Нужно продумывать взаимодействия объектов, то как объекты будут выглядеть и функционировать. А уже ПОТОМ думать о том как они будут хранится.
Потому как если вы начнете с определения БД и уже далее будете от этого отталкиваться, то это наложит свой отпечаток на реализации. А если вы сначала реализуете логику работы, то как сущности будут между собой взаимодействовать, то может вообще увидите, что вам лучше использовать документоориентированную БД вместо реляционной.
P.S. уверен есть и маститые парни которые которые за code-first подход :)
А почему «пишу самое правильное определение» это не тождественно равно «подразумеваю под моделью»? Синонимы как по мне.
Дак а я не увидел опровержений. Модель — это все что касается бизнес-логики. У Фаулера (с ваших слов) Модель — это все что не UI. Чем мое определение хуже, чем у Фаулера?
Касаемо DDD — термина модели нет, есть Агрегат, Сущность, VO — что по факту является детализацией/конкретизацией термина «модель»
Если бы я писал про DDD, я бы изначально ввел ряд терминов для понимания о чем речь. В данной статье использовался термин Модель, с смыслом описанным вначале.
Занятное чтиво бы получилось. И наверняка нашелся бы тот (или какая-либо концепция), чье понимание я не отразил. Так что слово «модель» в рамках данной статьи, отражает именно то, что написано в статье.
Никогда бы не подумал что краткий референс на Domain Model сломает до такой степени понимание.
Причем когда мы говорим про AR, такого вопроса почему то не возникает, и по-умолчанию понятно что является моделью. Хм…
Агрегат (Aggregate) – самостоятельный объект, имеющий идентичность.
Сущность (Entity) – несамостоятельный объект, имеющий идентичность.
Значение (Value Object) – несамостоятельный объект, не имеющий идентичности.
Про эти агрегаты речь? Если да, то определим, что моя концепция не разделяет эти 3 сущности и все 3 является моделями. Собственно при ТАКОМ контексте, в чем проблема?
Выше (в другой ветке) уже писали, что в концепции MVC, модель — это все что не касается интерфейса. Поэтому по факту M включается в себя слой данных и домена, а C — представляет из себя слой приложения. И где-то рядом еще сервисный слой должен лежать.
Не нужно ограничивать себя рамками MVC и считать, что модель — это база (повторюсь, это неверно).
«Модель» != «Domain model», а «Модель» = «Domain object». Я вроде уже раза 4-5 это обозначил.
Мы вроде выяснили что я понимаю не так как Вы, а ваша аргументация почему мое понимание не ложится в концепцию DM слабо выглядит.
Определение Фаулера (краткое):
Объекты отражающие сущности бизнес-логики (о чем в статье и речь). Если вы это определение воспринимаете иначе, то это уже проблема восприятия, а не формулировок.
Я и не провозглашал, что мое мнение истина в последней инстанции. Я лишь сказал что модели — это исключительно бизнес-логика. И это мнение правильное для меня, и абсолютно не ложится в термины MVC. Я эту идею транслирую, так же как Фаулер транслирует свою. Это разные точки зрения (да и по большому счету «о разном») и как-то сравнивать 2 термина из разных концепций странное занятия (естественно у Фаулера запас доверия куда бооооооольше, но это не значит что мое мнение ничего не стоит).
Окей, разберемся в терминах. Чуть выше я привел пример объект «деньги», который по моему мнению тоже модель (без поведения, просто данные). Вы говорите что это не модель, а объект домена — все верно?
Т.е. модели — это то что отражает объекты предметной области (неважно есть поведение или нет), а объекты домена — это вспомогательные сущности без поведения предметной области?
Вы делаете Модель «тупым» хранилищем с которым проводит какие-то операции Контроллер. Таким образом вы раздуваете контроллеры и даете им слишком много ответственности. Перемешиваете слои домена, сервиса и приложения, ну и т.д. Такой проект в последствии будет проблематично расширять и поддерживать.
В данном случае я думаю стоит быть категоричным, т.к. тут нет «относительности». Большой контроллер с массой ответственности — плохо при любом раскладе.
Да, каюсь, некорректно привел информацию о модели в парадигме MVC, но речь в статье НЕ заключалась в объяснении MVC, а рассмотрение конкретного примера работы с моделями.
А в чем тут ложность? Вы сами приводите сноску о том, что модель — это объект предоставляющий информацию о домене. По вашему домен != бизнес-логика?
А что в вашей сноске подтверждает ваше утверждение? Модель и сущность — это термины означающие одно и то же: объект предметной области обладающей поведением и данными данной предметной области. Если вы имеете ввиду различные вспомогательные ValueObject и определяете их как сущности — это опять вопрос терминологии. Даже если мы возьмем такой пример VO как «деньги», то это тоже модель, но без поведения как такового.
Вообще не подтверждающая цитата. Здесь лишь говорить о том что модели могут раздуваться до огромных размеров, но это уже вопросы проектирования и реализации, а не подхода как такового. В статье идет разделение на «целое и часть» в рамках конкретной сущности бизнес-логики (например «пост — комментарий»).
То есть допустим, если у нас есть объект «Департамент», который действительно может быть большим, НО большой объект != сложный объект. Если декомпозировать эту модель на его «части» и логику реализовать с помощью бизнес-операций (пример реализации в статье), то объект будет просто большим, но ничуть не сложным.