maleks писал(а): ↑2019.10.01, 17:26
Да язык тут вообще не причем. Книги по ООП и архитектуре идут вообще без привязки к какой то реализации.
Прекратите рассказывать мне о теории. На практике сначала потренеруйтесь на разных языках, тогда расскажете о том, как всё одинаково готовится.
maleks писал(а): ↑2019.10.01, 17:26
Ну так у меня в репозитории и будут выборки с AQ.
Только у меня будут эти выборки в одном месте, а у вас Post::find()->where() будет размазано везде, в контроллерах, виджетах, моделях и вьюхах
Не делать выборки в виджетах и вьюхах можно и без репозиториев - это первое. Второе - у Вас нет репозитория. У Вас бестолковый объект, поймите уже это и прекращайте рассказывать про репо с AR и AQ.
maleks писал(а): ↑2019.10.01, 17:26
Какой то бессмысленный набор слов. Я сказал что у вас он работает тупо как замена mysql_query() потому и не нужны вам beforeSave. А у меня он как
задумывалось
Вы мне цитируете Елисеева, подкидывая своих словечек. Откуда Вы знаете, что у меня работает и как? У меня нет Валидации в AR, у меня AR имеет бизнес логику, которая уместна в нём, на мой взгляд, я не горожу кусок чего-то дурнопахнующего, называя это репозиторием, я использую или сервисы для определённых действий или шину команд, когда что удобнее. У меня нет выборок в View. Получается, что все проблемы, которые Вы решаете своей реализацией "clear architect" - это ваша неопытность, не более. И Фаулера уж перестаньте сюда кидать ссылки. У Вас всё, как задумывалось, но в голове, почему-то каша.
maleks писал(а): ↑2019.10.01, 17:26
Про тайпхинт пока единое замечание по сути. А вот если его тут еще и валидировать то как то неорганично получится.
Валидация там по сути нужна в зависимости от выбраной стратегии (не Strategy паттерн) сохранения. Если используете, как я думаю, различного рода форматирование и чистку содержимого статьи (Purifier например), то может понадобиться проверка на допустимый размер контента, помимо самого typehint'а. Опять же, зависит от того, когда и где Вы производите эти действия.
maleks писал(а): ↑2019.10.01, 17:26
опять пустые закидоны
Не закидоны, а просто тупо надоело уже говорить 100 раз одно и то же.
maleks писал(а): ↑2019.10.01, 17:26
сказочки эти оставьте кому то другому. Ничего уровнего подобного данной серьезной задачи вы не расшарили с сообществом и не поддерживаете как расширение
Я разве сказал, что я выкладывал подобное расширение? Вроде нет. Задача нисколько не серьёзная, а наоборот вполне тривиальная для большей части проектов. Если Вы не понимаете философию NS и не можете реализовать управление NS на "голом" Query, то тут уже это Ваши проблемы, но приравнивать к себе остальных не нужно. Шарить и поддерживать такое расширение и не собираюсь, для Ваших проектов оно явно не подойдёт.
maleks писал(а): ↑2019.10.01, 17:26
Это больше ваши перекосы в восприятии.
Я пишу код, в соответствии с правилами всех этих статей, и смотрю насколько понятным он получается, а люди уточняют.
Это именно Ваши перекосы в восприятии. Вы пытаетесь создать серебряную пулю, внося в проект бестолковые объекты, тем самым не думая о памяти и других важных вещах. Хотите вечно читать теорию? Да читайте на здоровье. Хотите практиковать - отчасти прислушивайтесь к тому, что Вам говорят "коллеги по цеху" и пробуйте это на практике. Чаще всего, теория остаётся теорией и на практике делается всё иначе. Мы разрабатываем программные продукты, которые, к сожалению, никогда не будут иметь идеальный код. Прежде всего поймите, что описанные в этих статьях подходы - это решения. Решения конкретных проблем. А Вы, получается ничего не решаете, просто усложняете жизнь себе.
maleks писал(а): ↑2019.10.01, 17:26
Да, я помню вы все горели желанием по всем этим правилам цмс-ку собрать, но потом пришли такие, ой у меня ничего не получилось, все фигня. Что этому могли быть за причины?, учитывая вашу как бы так сказать
специфичную трактовку ООП, когда даже момент про Low coupling вами не понят, хотя уж о чем, а о нем как раз в каждой ООП книге орут.
Да, было дело, хотел сделать систему, близкую DDD. Болел, как и Вы архитектурой. Теперь имею закрытую, если это можно назвать CMF (Хотя по сути это удобная админ панель для определённого набора компонентов приложения для быстрого старта работы с проектами), на которой, например сейчас реализовывал работу с 6 базами (любительский сервер онлайн игры), так там пул соединений, но единая сущность, работающая с 2 базами. И представляете... Это всё AR! Да ещё и данные об аккаунте в 2 разных базах. Например пароль в одной, а логин в другой. Всё красиво, сущности имеют только необходимую бизнес логику, остальное в сервисах. Вот такая система из этого вышла. Но в опенсорс она не попала в виду того, что она не предназначена для домохозяек и прочего контенгента. Она специфична и используется для проектов, которые разрабатываются узким кругом разработчиков. Хотя до сих пор хочу CMS сделать, как и раньше.
Касаемо "непонятых мной моментов", трактовок и т.п. скажу так, что бы не обидеть: не нужно оценивать мои возможности, оценивайте свои. Я давал оценку Вашей архитектуры, т.к. Вы создали данную тему и написал о том, что, по моему мнению не так. Не хотите прислушаться, то хоть не начинайте мне навязывать Ваши, где-то на просторах прочитанные куски теории, которые по большей части Вы не сможете применить на практике.
maleks писал(а): ↑2019.10.01, 17:26
Так в этом то и суть. Мне не нужно дорого и очень сложно.
Уже писали много раз о том, что серебряной пули не бывает. Хотите просто - AR и не выдумывайте лишнего. Нужно красиво - это будет сложно и дорого в любом случае.