@phpclubru

Страница 248 из 956
 
Roman
20.06.2017
09:30:27
DTO, POCO, SOLID

 
Roman
20.06.2017
09:30:36
И те статьи, что я кинул, там есть ссылки на оригинал

 
2 хороших статьи по теме: https://habrahabr.ru/post/268371/ https://habrahabr.ru/post/275599/

 
Только нужно не впадать в крайности и не юзать паттерны ради паттернов) Главное - чистый и работащий код

Google
 
Roman
20.06.2017
09:31:47
Видимо мне не стоит лезть в эти мастерские баталии

 
Adel
20.06.2017
09:31:52
ну в DDD то как раз вся логика в энтитиях. то о чем ты говоришь это подход анэмичный. когда обьект не содержит вообще никакой логики.

 
Roman
20.06.2017
09:31:58
и просто определиться с реализацией

 
Adel
20.06.2017
09:32:12
да. просто сделай какнибудь :)

 
опираясь на то что здесь услышал.

 
Roman
20.06.2017
09:32:22
DDD - это не только Entity

 
Roman
20.06.2017
09:32:34
главный вопрос - стоит ли открывать свойства

 
Adel
20.06.2017
09:32:42
и если чтото не так, то твой код сам тебе подскажет.. он будет сопротивляться противоестественным изменениям..

 
Roman
20.06.2017
09:32:44
Видимо мне не стоит лезть в эти мастерские баталии
Статьи простые, прочитай просто для ознакомления

 
Roman
20.06.2017
09:32:45
или всё же заставить себя написать по строчке кода сеттеров

 
Roman
20.06.2017
09:33:05
PhpStorm генерит сеттеры сам

 
Roman
20.06.2017
09:33:26
дорого стоит

 
не потяну

Google
 
Roman
20.06.2017
09:33:41
Тут половина чата сидит на пиратке)

 
Roman
20.06.2017
09:33:47
лицуха 500 долларов?

 
Roman
20.06.2017
09:33:48
NetBeans

 
Pavel
20.06.2017
09:34:01
Всем привет! Ребят, может кто-нибудь подскажет подходящий паттерн под кейс? Есть модуль/подсистема уведомлений. Она умеет рассылать разные уведомления по разным каналам (почта, смс, вебхуки и т.п. ). Уведомяет она о разных событиях касающихся разных сущностей, например, заказы и товары. В этом модуле реализован механизм правил, который в зависимости от срабатывания правил определяет надо производить уведомление или нет (например, пользователь подписан на этот товар, или был сформирован заказ на определенного продавца). Эти правила могут использвать специфичные характеристики сущностей (например, артикул товара) или общие для разных сущностей (например, время создания/изменения), но в тоже же время одинаковые характеристики могут храниться в разных полях сущностей (иметь разные интерфейсы для доступа к ним). Чего хочется: получить систему, которая может однообразно работать с разными сущностями и код был бы чистым, без сильного нарушения SOLID. Сейчас на вход передается EntityInterface, который затем в правилах проверяется на тип (заказ/товар/...), и из этих сущностей получаются необходимые для работы правила данные. Мне не нравятся в коде вот эти instanceof. При добавлении новых сущностей придется править все правила и добавлять проверки на новые сущности. Здесь бы хорошо легли generics, но в пыхе их нет ( Как вариант, можно попробовать заюзать Visitor (не нравится тем, что опять таки придется править кучку классов при добавлении новой сущности), или Adapter, который будет инкапсулировать интерфейс доступа к полям сущностей (не нравится тем, что в интерфейсе будут методы, которые не специфичны для некоторых сущностей и интерфейс будет раздут). Может у кого-то уже была подобная задачи и было решено более чисто?
Не совсем понятна задача. Ну можно сделать отдельную таблицу всех типов уведомлений на эвенты и подписывать пользователя на id из этой таблицы

 
Adel
20.06.2017
09:34:33
лицензия помоему 50+ баксов в год

 
но также есть EAP программа.. там можно долго сидеть

 
и генерации его.. спасают тонны времени

 
Roman
20.06.2017
09:35:04
лицуха 500 долларов?
Почему? > US $ 89.00 /1st year US $ 71.00 /2nd year US $ 53.00 /3rd yr onwards

 
Netbeams бесплатный и тоже умеет, но я уже давно им не пользовался

 
главный вопрос - стоит ли открывать свойства
Стоит, если они предполагают изменения и не стоит, если не предполагают)

 
Roman
20.06.2017
09:38:07
Стоит, если они предполагают изменения и не стоит, если не предполагают)
ну вот у меня в контроллере метод

 
который обрабатывает УЖЕ отправленную форму заявки

 
я создаю объект, потом пишу в открытые свойства данные с формы

 
и просто в конце метод save

 
после этого можно сразу же unset($object)

 
Roman
20.06.2017
09:39:04
Ну по-хорошему у тебя обработчик формы должен вернуть уже DataObject

 
А потом еще и провалидировать, удалить невалидные данные и вернуть список ошибок, если невалидные

 
А если валидные, то ты просто берешь объект и сохраняешь

 
Roman
20.06.2017
09:40:26
На сеттеры писать проверку валидности - зло

 
Значит проверку валидности впихну в save

Google
 
Roman
20.06.2017
09:40:38
Нет

 
Roman
20.06.2017
09:40:39
сразу же все поля проверю

 
Roman
20.06.2017
09:40:58
Валидацию лучше вообще вынести в отдельный класс ну или метод хотя бы

 
Смотрел симфонивский валидатор?

 
Roman
20.06.2017
09:41:13
Нет

 
Я боюсь симфони вообще

 
Roman
20.06.2017
09:41:19
Посмотри

 
Он довольно удобный. Аннотациями задаешь правила для валидации и валидируешь

 
Не хватает .. и profit

 
Roman
20.06.2017
09:41:52
аааа

 
это видел

 
Adel
20.06.2017
09:42:02
надеюсь он хотя бы в базу не лезет.. как ларавелевский...

 
Roman
20.06.2017
09:42:04
преподаватель показывал

 
Roman
20.06.2017
09:42:12
А нахуя ему в базу то лезть?

 
Adel
20.06.2017
09:42:24
так эти ларавелевские козлы придумали!

 
https://laravel.com/docs/5.2/validation#rule-exists

 
вон глянь...

 
до сих пор зла не хватает

 
Roman
20.06.2017
09:43:27
Значит проверку валидности впихну в save
Если тебе много переделывать придется, можешь просто принимать форму массивом, валидировать и потом создавать объект и сохранять

 
Roman
20.06.2017
09:43:50
Если тебе много переделывать придется, можешь просто принимать форму массивом, валидировать и потом создавать объект и сохранять
да...

Google
 
Roman
20.06.2017
09:43:53
я так раньше и грешил(

 
валидность проверял в контроллере

 
Roman
20.06.2017
09:44:02
Только не save($array), а как-нибудь (new Ticket($data))->save()

 
А потом воткнешь нормальный валидатор)

 
Roman
20.06.2017
09:44:14
а не

 
я думал тупо $ticket->save();

 
потому что сейвиться будут данные уже в свойствах

 
Roman
20.06.2017
09:44:51
Это тоже самое

 
Roman
20.06.2017
09:44:53
диссертацию сдавать в пятницу в 9 утра

 
в рамках диссертации нужно сделать как-то

Admin
ERROR: S client not available

 
Roman
20.06.2017
09:45:05
а потом переделывать сколько угодно

 
Roman
20.06.2017
09:45:16
Ну так делай, а не обсуждай)

 
Roman
20.06.2017
09:45:26
может я тогда всё же сделаю public свойства?

 
ок

 
Adel
20.06.2017
09:45:39
ой блин :)) студент.. сделай хоть какнибудь! преподу пофиг

 
он сам хуже тебя разбирается. я почти уверен :)

 
Roman
20.06.2017
09:46:06
он вообще не будет смотреть код

 
на защите я буду показывать морду и как всё работает для юзера

 
Roman
20.06.2017
09:47:35
https://laravel.com/docs/5.2/validation#rule-exists
Ну в целом нормально, метод проверяет, что для роут вида /entity/{id} существует entity с нужным id

Google
 
Adel
20.06.2017
09:47:55
ок. оно проверяет.. везде

 
Roman
20.06.2017
09:48:04
В симфони для этого есть ParamConvertor'ы, которые тебе сразу в контроллер передадут Entity или вернут 404

 
Adel
20.06.2017
09:48:06
а потом мы добавляет soft delete

 
добавляем*

 
Roman
20.06.2017
09:48:19
Ну никто не мешает не использовать такой способ валидации

 
Adel
20.06.2017
09:48:25
я мешаю!

 
буду бить по пальцам

 
Pavel
20.06.2017
09:49:17
а потом мы добавляет soft delete
Soft delete это вообще очень сложная тема, даже независимо от валидаторов

 
Adel
20.06.2017
09:49:30
да там любую логику добавь и оно сломается

 
потмоу что лезет в базу.. тупая валидация.. лезящая в базу..

 
Pavel
20.06.2017
09:50:42
А как тогда по правильному проверить что объект не существует в базе при вводе пользователем?

 
Adel
20.06.2017
09:51:04
внутри логики. не на этапе валидации, где мы лишь должны отсеять мусор

 
а дальше

 
когда попытается сделать бизнес-действие

 
выкинем эксепшен

 
Pavel
20.06.2017
09:53:31
Ну это же может быть 1й шаг заполнения формы из 5 например )

 
В общем для небольших проектов я считаю ок лезть в базу при валидации

 
Adel
20.06.2017
09:55:28
ты мой идеологический враг :)

 
Pavel
20.06.2017
09:57:40
Сама реальность любит прессовать идеологии

 
Ну или например вот заполняет человек форму из 32 полей, и неплохо бы ему подсказать аяксом что его емейл введенный в поле уже зарегистрирован

 
sergey
20.06.2017
09:59:48
зачем? пусть все заполнит, а потом ему просто надо написать "ошибка".

 
))

 
Pavel
20.06.2017
10:01:07
И все поля стереть еще? Изверг!

Страница 248 из 956