Плохо так делать. Есть 1 случай, где использование переменных переменных оправдано, и то можно обойтись без этого. Это удобно, например, для валидации DTO, где валидотор принимает массив атрибутов с правилами валидации и обращается к полям объекта так
Аутентификация по сути есть частный случай авторизации.
Если нужен текущий пользователь, его сперва нужно аутентифицировать, а что делать дальше, добавлять авторизацию на "взятие книги" или нет, дело второе.
Опоздал на пару месяцев, но все-же дам ссылочку, может кому-то будет интересно. https://habrahabr[dot]ru/post/342434/ (Добавление)
Ну и гугл в помощь с запросом "нечеткий поиск"
здаров.
скажи че дельное, обсудим. я за дебаты. свою точку зрения не отстаиваю, потому готов услышать мысли оппозиции ))
и да, я за SOLID, за правильное наследование, хоть это к теме и не относится.
и я не понимаю, что тебя так смутило!
В рамках DDD, Application layer не знает деталей хранения данных.
Application layer это сервисы, которые производят какие-то действия над твоими объектоми модели.
Data Storage Layer - это репозитории, которые используются в сервисах.
Код, который ты привел, не вписывается никаким боком в DDD, это и не сервис, и не репозиторий. Больше похоже на контроллер, и то сложно это назвать контроллером.
И что такое generic wrapper?
Я похоже отстал от сегодняшних реалий ))
Разберись сперва с базовыми концепциями DDD, потом приходи. (Добавление)
Почитай цикл статей по ссылке, которую я привел выше.
Там доходчиво описывается, что такое доменная модель, сервисы и репозитории.
Если интересно, могу скинуть все сортировщики написанные на C++ (можно скомпилить в VS2015), там есть
Quick Sort, Selection Sort, и множество алгоритмов сортировки Шелла.
К тому-же пргграммка делает замеры эффективности по времени, и количество перестановок и сравнений.
В тонкой модели вся логика приложения живёт в контроллере.
Стоило предупредить, что это плохая практика, а то топикстартер может принять это за постулат.
Я предпочитаю тонкие модели и тонкие контроллеры - никакой бизнес-логики в контроллере быть не должно, только логика обработки запроса.
Для бизнес-логики более подходящее место это сервисный слой (он-же Application layer). В таком случае, БЛ можно повторно использовать в любом месте.
В кратце:
- модель содержит логику для поддержания своей целостности и валидности
- сервис содержит логику для обработки модели (например, сервис может сохранять модель осуществляя дополнительные проверки)
- контроллер принимает запрос, обрабатывает его и отдает ответ
Мелкий пишет:
Отдельный холивар: готовит ли контроллер все данные для представления или представление может самостоятельно дёргать модели для получения интересующих данных.
Исходя из вышесказанного, контроллер лишь передает данные во вью слой, а он уже готовит, как ему надо.
Мелкий пишет:
Ещё холивар современного веба - а где вообще находятся контроллер и представление, на сервере или на клиенте?
Не понимаю, почему холивар? И там и там может быть.
Мелкий пишет:
Не на каждую. Всё-таки контроллер обычно объединяет группу логически связанных страниц.
Просто хочу добавить. В Магенто 2, контроллер это строго 1 действие. Но не будем о плохом.
Мелкий пишет:
При этом с точки зрения PHP весь view - одна стартовая страничка.
Не соглашусь. Вью это не только HTML.
Вью это слой трансформирующий данные модели в другой вид, например, JSON, XML или HTML.
Следуя из этого, практически каждое обращение к API приложения (к ендпойнтам, а не API классов) влечет за собой трансформацию данных в другое представление, так, что по сути вью это не только стартовая страничка.
Это мое мнение, и оно не претендует на истину в последней инстанции.
Если под ООП подразумевается ООПрограммирование, то, чтобы это было ООП, нужно соблюсти всего 2 условия - инкапсуляция и абстракция.
Если ООПроектирование, то это очень философский вопрос, однозначного ответа нет.
Но такая многослойная архитектура довольно распространена.
ВеликийПрограмист пишет:
Как это реализовать, а именно разбить на Application и Domain слои есть какие-то примеры?
И зачем нужно Data Storage Layer понятно чтобы можно было легко поменять базу данных, но можно же сделать Wrapper зачем целый отдельный механизм заталкивания в базу какой в этом смысл?
По хорошему, твой код ничего не должен знать о том, как и где хранятся данные, и как их от туда доставать. Вся эта магия должна быть заключена в 1 месте - в репозиториях. Репозиторий это по сути фасад над хранилищем данных, который предоставляет простой и удобный интерфейс для доступа к данным.
Сперва неплохо бы выучить наизусть формулировки инкапсуляции, абстракции, наследования и полиморфизма, ну и попытаться их понять.
Затем, почитай про самые часто-используемые паттерны, например, фабрика, стратегия, фасад итд.
Выбери 2-3 понравившихся и досканально их изучи.
Что касается SOLID, что бы понять их всех, нужно много реальной практики.
Меня всегда удивляли требования работадателей для джуниоров - знание SOLID.
Как минимум, это абсурдно.
Что бы произвести более хорошее впечатление на собеседовании, почитай про тесты и DDD.
Не нужно изучать DDD полностью, это довольно объемная и сложная методология, возьми на вооружение базовые концепции и паттерны.
Пусть это будет уже не DDD, но + к скилу гарантирован.
Ну и еще, обязательно почитай про антипаттерны, на собеседованиях, бывает, спрашивают.
Например, могут спросить чем плох Active Record (хоть это и не антипаттерн, но + и - знать нужно).
Можно расписовать бесконечно, давай лучше задавай вопросы.
поддерживает ли mysql 5.7 поиск с учетом русской морфологии?
в официальных источниках не нашел такой информации, но некоторые люди говорят, что поддерживает.
какие то "принятые" вещи, которые, как по мне, тянутся еще со времен консольных интерфейсов.
Мой главный критерий это личное удобство, а не чье-то там, кто рекомендует.
Для серверов, да, лампы уже излишни, 1 раз поставил окружение, настроил.
Для дев-машин, мне удобней иметь стек, в котором можно парой кликов переключить окружение и работать дальше.
Только не надо свою религию впаривать. Принято, не принято, какая мне разница что там принято.
Если lamp мне удобней, то я использую его, несмотря на догмы где то там принятые.
Ch_chov пишет:
Для переключения между версиями есть Virtual Box, Vagrant, Docker.
Основная причина перехода на линукс это слабый процессор (селерон). А все это излишне его нагружает, + если запущен phpstorm то вапще жопа.
Поправьте, если ошибаюсь.
Главная
Помощь
Поиск
Пользователи
Найдено сообщений: 2732
