Как бы вы комбинировали реализацию таких фильтров?
Для регионов нужна валидация вложенных домов, для занятых регионов — еще и по застройщикам валидация — т.е. помимо своих, надо еще и дочерние валидировать — в этом и смысл Specification Pattern.
Глобально повесить, например, фильтрацию для выборок только сущностей Region, House, DeveloperCompany, а на версии сайта застройщика еще и фильтр по застройщику давать на всё это дело — вообще не вариант, слишком неявно.
Оно хорошо, когда есть очевидные вещи — игнорировать по is_deleted=true и так далее, но бизнес я бы в такие вещи не заносил.
У меня очень мало опыта с DDD, пока имеется только лишь громадный интерес ко всей этой теме и боль в спине от несостыковок между конечным вариантом фичи и волшебными требованиями в голове заказчика и арт директора .)
Ну а так все верно, тут Domain Layer и Persistence Layer в достаточной мере размыты. Но опять же, применять Specification Pattern уже на коллекцию сгидрированных со стоража доменов не получится в силу банального fatal out of memory error.))
Не у всех есть DDD и такой вариант со спецификациями я думаю лучше чем первый, когда дублируются эти правила в репозиториях.
Вообще, если с точки зрения DDD это не какой-то банальный кейс, я бы очень хотел услышать ваше мнение, как и что Вы бы применили для решения подобных проблем.
Пишите на том, что вам нравиться, а не что финансируется. Как по мне и codeigniter вполне нормальный для разработки, если голова на плечах есть. Ничто не мешает сделать на нём сложный проект с любой архитектурой, было бы желание его в достаточной мере изучить.
Ну если безответственно подходить к вопросу выбора стека технологий, например, для домашнего проекта, то все ок.
А так сразу вспоминается любимая Коханочка, которая резко и неожиданно прикрылась к чертям собачьим. Вот это была жопка, мало того, что все сразу начали усилинно линять с фреймворка, так еще через какое-то время х*як — https://habrahabr.ru/post/150201/
И это не нормальное состояние проекта, за который тебе платят деньги.
И про Symfony Flex советую побольше почитать, много интересного на самом деле планируется, симфони практически стало единственным в мире PHP, что достойно внимания.
Чисто из интереса, даже и про недавний 3.3 релиз можно почитать, ибо много добавлено плюшек с DI.
Т.е. ребята реально работают и делают нашу работу удобнее.
Разве не правильнее было бы юзать продукт, у которого уже сейчас имеются LTS релизы, ком. поддержка и прочее в проекте, который планирует достаточно долго развиваться?
Что мы сделали для Yii, чтобы он стал лучше? А зачем, когда уже сейчас есть Симфони, который во всю финансируют?
Тем временем в Yii как известно, один из основных разработчиков ушел в Go.
Зачем тратить деньги на доработку Yii, если можно взять Симфони прямо сейчас и быть уверенным в завтрашнем дне и в выходе Symfony 4 Flex в ноябре?
Отстутсвующие фичи из других фреймворков либо настолько редко используются, что никому не нужны, либо просто их никто не просил. Так мы не против допила контейнера, если в этом есть необходимость. Если вам лично нужна какая-то фича, опишите почему в issue и мы вместе подумаем над решением.
Так в этом и проблема — Yii сообщество не знает, что им нужен нормальный DI, во всех примерах и уроках по Yii ни намека на контейнеры. В основном Yii::$app — это весь DI и в этом и есть весь выстрел в ногу, особенно, когда оно используется за пределами контроллера или команды.
Когда класс компонента юзает Yii::$app, он начинает мочь всё и вся, он перестает быть прозрачным и любой потенциальный юнит тест на него скорее всего бесполезен, ибо, например, замокать зависимость класса, которая юзается в компоненте через Yii::$app — не, ну никак.
Но сколько не спрашиваю, мало кто из Yii разработчиков этим обеспокоен и 99% просто не знают о mock\stub.
Данный фреймворк дает возможность делать всякую бяку из коробки, у него самый ужасающе низкий порог вхождения. И поэтому подавляющее большинство разработчиков максимально неопытны и формируют вредные взгляды о PHP cообществе в целом.
Ну вряд ли нам конечно предоставят какой нибудь ИИ, который будет делать за нас все + еще и тапки приносить. Скорее всего произойдет снятие определенных рамок и немного философии о свободе прав кода и правильной расширяемости приложения. Symfony Flex будет давать возможность управлять приложением гибко (на то он и Флекс), позволит наращивать только в нужном направлении, т.е. не иметь никаких стен.
Пример даже из статьи, если нам нужен REST + Admin, то мы больше не будем нуждаться в целом дистрибутиве под это дело, т.к. теперь мы можем свободно нарастить наше приложение, добавив как REST, так и Admin — и всё это без мяса и с львиной долей гуманизма и жвачки. Композицию наследованию!!!
«Symfony Flex должен привнести к искоробочности еще и гибкость выбора» — цитата одного из разработчиков в чате.
Аналогию я проигнорировал, потому как она вообще никак не связана с тем, что я пытаюсь донести.
Я про подход к решению задач, вы — про велосипедостроение. Где я говорю о том, что надо сидеть и писать свои решения с 0? Я говорю о том, что к вопросу надо подходить фундаментально — это позволит потом быстрее и дешевле (раз уж речь зашла о предпринимательском духе) реализовывать что угодно, без необходимости прочтения книг, прохождения видеокурсов для решения той или иной задачи.
Нельзя же полностью понять устройство двигателя самолёта без знаний физики, термодинамики, электрики, механики и аэродинамики, но можно найти кукбук, где это все можно собрать скотчем и продать, да?
И в этом есть только один плюс: чем больше неквалифицированных кадров, тем больше заработная плата у реальных специалистов.
P.S:
Главное чтобы дорабатывать ничего после таких умельцев не приходилось никогда.
Получить список сообщений с вк — тут много ума не надо. Поиск информации о решении данной проблемы — неверный путь, но возможно простительный для начинающих, если есть куда стремиться.
Писать вот такие статьи на каждый случай — это обрекать все больше и больше народу на невозможность правильно работать с документацией и задачей априори. Под «такими» статьями я понимаю абсолютную бесполезность. Здесь не описывается как работать с конкретной либой например, какие у нее есть фишки, которые мы можем применить и получить определенный профит, как нам лучше оптимизировать ту или иную штуку. Здесь просто получение всех сообщений, ненужное описание как записать все в файлик ну и + «олгоритхм» как пройтись по всем сообщениям, просто прибавляя offset, который может реализовываться через execute процедуры вк, вот и всё.
А сама проблема в том, что таким образом формируются абсолютно некомпетентные «специалисты» на IT рынке. Я вот из мира PHP и смею утверждать, что мы там лучше всех знаем таких умельцев, порожденных DVD-курсами Русакова и Попова, которые формируют коробочное мнение о задачах и отдаляют людей от математики и программирования как такового. Точно так же и здесь: поиск информации в таком ключе порождает то же коробочное мышление. А это именно некомпетентность специалиста, формируемая прогрессирующей невозможностью решать реальные проблемы.
Кстати по-поводу «Обходить капчу», такая библиотека для работы с VK api есть, если кому то интересно. Правда надо будет не забыть поменять AppID, для удобства там авторский стоит.
Captcha Handler можно как раз установить свой + вроде бы был готовый вариант с anti-captcha.com. И как раз для лентяев — всё на русском языке, сам автор тоже оперативно выходит на связь. И так даже посмотреть если, то проект вроде бы еще живет.
А разве это хорошо, если программисты будут гуглить именно это?
Как по мне, так надо гуглить «vk get messages», «vk api python», а так, если всем разжевывать подобные задачи, то программисты, которые на этом вырастают, уже не могут ни ходить, ни решать реальные бизнес проблемы самостоятельно, им всегда будет не хватать целых книг следующего плана: «Как нажать на кнопку», «Как сделать свой интернет магазин», «Как сделать корзину на сайте», «Как сделать комментарии на сайте», «Как сделать голосование на сайте». Хотя истина лежит в поиске ответов на вопросы: «SQL для начинающих, база данных», «Основы framework».
К тому же решение кривое, перебор и обновление offset вполне себе делается через создание своей процедуры для API.
Ладно бы еще это была какая-то особенная библиотека для работы с ВК API на пайтоне, где можно было бы допустим обходить капчу через AntiCaptcha API и прочих сервисов такого плана и обзор всех этих дел. (vk_api)
Вообще по логике да, в статье чисто пример DQL.
Тут речь скорее о том, что конкретно данные поставляет в обработку с фрондента, в данном случае это была просто форма с datepicker-ом, прибавляем к нему timepicker и у нас все замечательно работает.
В примере с DQL данные проставлялись в формате DATE, а не DATETIME, поэтому время было равно 00:00.
Полностью соглашусь.
Но какой смысл было рефакторить, создавать сервисы для всего этого дела, если задача стояла — максимально просто объяснить, как можно сделать фильтрацию данных из формы?
Вообще, у меня бы это выглядело примерно так — https://gist.github.com/anboo/b01a49240323e5ad44b75c0372dc3810
Можно услышать ваше мнение по-поводу этого?
Помнится когда-то в одноклассниках была уязвимость с возможностью сделать редирект при переходе на ссылку со страницы ok.ru
В итоге злоумышленники спокойно выкладывали ссылки, которые по-сути выглядели безобидно, тем временем как вкладка с одноклассниками открывала фишинговый сайт, практически незаметно для пользователя.
Сейчас вроде переходы на ссылки централизованы и работают через специальный интерфейс одноклассников, но тогда были веселые времена :)
Вроде как через window.opener проводилась атака.
Для регионов нужна валидация вложенных домов, для занятых регионов — еще и по застройщикам валидация — т.е. помимо своих, надо еще и дочерние валидировать — в этом и смысл Specification Pattern.
Глобально повесить, например, фильтрацию для выборок только сущностей Region, House, DeveloperCompany, а на версии сайта застройщика еще и фильтр по застройщику давать на всё это дело — вообще не вариант, слишком неявно.
Оно хорошо, когда есть очевидные вещи — игнорировать по is_deleted=true и так далее, но бизнес я бы в такие вещи не заносил.
Ну а так все верно, тут Domain Layer и Persistence Layer в достаточной мере размыты. Но опять же, применять Specification Pattern уже на коллекцию сгидрированных со стоража доменов не получится в силу банального fatal out of memory error.))
Не у всех есть DDD и такой вариант со спецификациями я думаю лучше чем первый, когда дублируются эти правила в репозиториях.
Вообще, если с точки зрения DDD это не какой-то банальный кейс, я бы очень хотел услышать ваше мнение, как и что Вы бы применили для решения подобных проблем.
Ну если безответственно подходить к вопросу выбора стека технологий, например, для домашнего проекта, то все ок.
А так сразу вспоминается любимая Коханочка, которая резко и неожиданно прикрылась к чертям собачьим. Вот это была жопка, мало того, что все сразу начали усилинно линять с фреймворка, так еще через какое-то время х*як — https://habrahabr.ru/post/150201/
И это не нормальное состояние проекта, за который тебе платят деньги.
И про Symfony Flex советую побольше почитать, много интересного на самом деле планируется, симфони практически стало единственным в мире PHP, что достойно внимания.
Чисто из интереса, даже и про недавний 3.3 релиз можно почитать, ибо много добавлено плюшек с DI.
Т.е. ребята реально работают и делают нашу работу удобнее.
P.S:
http://school-assistant.ru/?predmet=russian&theme=pravopisanie_tsia_v_glagolax
Что мы сделали для Yii, чтобы он стал лучше? А зачем, когда уже сейчас есть Симфони, который во всю финансируют?
Тем временем в Yii как известно, один из основных разработчиков ушел в Go.
Зачем тратить деньги на доработку Yii, если можно взять Симфони прямо сейчас и быть уверенным в завтрашнем дне и в выходе Symfony 4 Flex в ноябре?
Так в этом и проблема — Yii сообщество не знает, что им нужен нормальный DI, во всех примерах и уроках по Yii ни намека на контейнеры. В основном Yii::$app — это весь DI и в этом и есть весь выстрел в ногу, особенно, когда оно используется за пределами контроллера или команды.
Когда класс компонента юзает Yii::$app, он начинает мочь всё и вся, он перестает быть прозрачным и любой потенциальный юнит тест на него скорее всего бесполезен, ибо, например, замокать зависимость класса, которая юзается в компоненте через Yii::$app — не, ну никак.
Но сколько не спрашиваю, мало кто из Yii разработчиков этим обеспокоен и 99% просто не знают о mock\stub.
Данный фреймворк дает возможность делать всякую бяку из коробки, у него самый ужасающе низкий порог вхождения. И поэтому подавляющее большинство разработчиков максимально неопытны и формируют вредные взгляды о PHP cообществе в целом.
Привет из 2017.
Пример даже из статьи, если нам нужен REST + Admin, то мы больше не будем нуждаться в целом дистрибутиве под это дело, т.к. теперь мы можем свободно нарастить наше приложение, добавив как REST, так и Admin — и всё это без мяса и с львиной долей гуманизма и жвачки. Композицию наследованию!!!
Я про подход к решению задач, вы — про велосипедостроение. Где я говорю о том, что надо сидеть и писать свои решения с 0? Я говорю о том, что к вопросу надо подходить фундаментально — это позволит потом быстрее и дешевле (раз уж речь зашла о предпринимательском духе) реализовывать что угодно, без необходимости прочтения книг, прохождения видеокурсов для решения той или иной задачи.
Нельзя же полностью понять устройство двигателя самолёта без знаний физики, термодинамики, электрики, механики и аэродинамики, но можно найти кукбук, где это все можно собрать скотчем и продать, да?
P.S:
Главное чтобы дорабатывать ничего после таких умельцев не приходилось никогда.
Писать вот такие статьи на каждый случай — это обрекать все больше и больше народу на невозможность правильно работать с документацией и задачей априори. Под «такими» статьями я понимаю абсолютную бесполезность. Здесь не описывается как работать с конкретной либой например, какие у нее есть фишки, которые мы можем применить и получить определенный профит, как нам лучше оптимизировать ту или иную штуку. Здесь просто получение всех сообщений, ненужное описание как записать все в файлик ну и + «олгоритхм» как пройтись по всем сообщениям, просто прибавляя offset, который может реализовываться через execute процедуры вк, вот и всё.
А сама проблема в том, что таким образом формируются абсолютно некомпетентные «специалисты» на IT рынке. Я вот из мира PHP и смею утверждать, что мы там лучше всех знаем таких умельцев, порожденных DVD-курсами Русакова и Попова, которые формируют коробочное мнение о задачах и отдаляют людей от математики и программирования как такового. Точно так же и здесь: поиск информации в таком ключе порождает то же коробочное мышление. А это именно некомпетентность специалиста, формируемая прогрессирующей невозможностью решать реальные проблемы.
Captcha Handler можно как раз установить свой + вроде бы был готовый вариант с anti-captcha.com. И как раз для лентяев — всё на русском языке, сам автор тоже оперативно выходит на связь. И так даже посмотреть если, то проект вроде бы еще живет.
Как по мне, так надо гуглить «vk get messages», «vk api python», а так, если всем разжевывать подобные задачи, то программисты, которые на этом вырастают, уже не могут ни ходить, ни решать реальные бизнес проблемы самостоятельно, им всегда будет не хватать целых книг следующего плана: «Как нажать на кнопку», «Как сделать свой интернет магазин», «Как сделать корзину на сайте», «Как сделать комментарии на сайте», «Как сделать голосование на сайте». Хотя истина лежит в поиске ответов на вопросы: «SQL для начинающих, база данных», «Основы framework».
К тому же решение кривое, перебор и обновление offset вполне себе делается через создание своей процедуры для API.
Ладно бы еще это была какая-то особенная библиотека для работы с ВК API на пайтоне, где можно было бы допустим обходить капчу через AntiCaptcha API и прочих сервисов такого плана и обзор всех этих дел. (vk_api)
Тут речь скорее о том, что конкретно данные поставляет в обработку с фрондента, в данном случае это была просто форма с datepicker-ом, прибавляем к нему timepicker и у нас все замечательно работает.
В примере с DQL данные проставлялись в формате DATE, а не DATETIME, поэтому время было равно 00:00.
Но какой смысл было рефакторить, создавать сервисы для всего этого дела, если задача стояла — максимально просто объяснить, как можно сделать фильтрацию данных из формы?
Вообще, у меня бы это выглядело примерно так — https://gist.github.com/anboo/b01a49240323e5ad44b75c0372dc3810
Можно услышать ваше мнение по-поводу этого?
В итоге злоумышленники спокойно выкладывали ссылки, которые по-сути выглядели безобидно, тем временем как вкладка с одноклассниками открывала фишинговый сайт, практически незаметно для пользователя.
Сейчас вроде переходы на ссылки централизованы и работают через специальный интерфейс одноклассников, но тогда были веселые времена :)
Вроде как через window.opener проводилась атака.
Добавил в статью, спасибо.