Всем привет,
недавно в соседней теме про Тесты было сказано, что "считается плохой практикой использовать на странице доменные объекты, вместо них используются DTO".
и вот подвернулся случай попробовать использовать этот подход на практике, который я выношу на обсуждение в данной теме по причине, что сам не до-думал как это правильно реализовать, а также это будет интересно другим, кроме того, как говорится, "две головы хорошо - а Gres или wilder - все равно лучше".
Есть VF страница которая называется "Бронирование", она состоит из двух списков: первый - это объекты бронирования, возьмем Комнаты, второй - это собственно записи Бронирования, и этот список представлен в виде слегка-интерактивной календарной сетки.
Таким образом на фронт подается два Листа доменных объектов: Комнаты__с и Брони__с (PS: на самом деле Брони подаются на фронт не в виде доменных объектов, а "перешиваются" в объекты, которые может принять календарный плагин на фронте).
также у контроллера есть методы:
(1) фильтровать Комнаты по параметру.
(2) фильтровать Брони по Комнате (этот Лист подается всегда фильтрованным).
(3) создание новой Брони__с
Ну и конечно, потребовалось "адаптировать" эту страницу к новым доменных объеткам.
Какие проблемы, сказано - сделаем.
Но вот думаю, что если сделать эту страницу\контроллер работающими на DTO, то такое "адапирование" значительно упроститься в будущем.
Как это лучше сделать?
Den, ты только открыл для себя что можно использовать DTO на страницах?
А как же ты раньше программировал?
Ну хорошо хоть поздно чем никогда.
Я наверное их начал использовать c начала знакомства с SF, когда даже не знал что это DTO и называл просто inner classes или wrappers.
На голых объектах далеко не уедешь, я даже не знаю куда на них можно уехать.
Подумай, может ты все-таки использовал раньше, просто не знал как это правильно называется?
Вот простой пример.
Есть список контактов, которые надо вывести на странице и для каждого контакта есть дополнительный чекбокс. Как ты это дело выведешь на странице?
конечно использую, почти в каждом контроллере, но эти классы описаны в каждом конкретном контроллере (кстати, как их правильно назвать?).
но тут, как я понял дело в другом.
в том, что контроллер работает с DTO объектами и выполняет операции, при этом "нюхом не зная", что за доменные объекты используются изначально или создаются в конце концов.
т.е. DTO - это вроде как прокладка, обобщенная вплоть до единсвенного DTO класса на все контроллеры.
выигрыш в том, что можно использовать контроллер с разными доменными объектами ничего не меняя в самом контроллере.
Это как я понял саму идею. Но не совсем ясно как ее реализовать.
или может даже создать для определенного функционала\страницы какой-то базовый контроллер, а потом наследовать от него суб-классные контроллеры для каждого конкретного случая, перезаписывая\добавляя функционал, но это только размышления...
Не усложняй все. Вот знаю один проект, тоже вот так вод думали, думали, выносили, создавали. Данные на страницу передаются через одни DTO, который наследуют другие DTO и создаются специальными классами сервисами. ЭТО ЖЕСТЬ! Все равно вся эта красота превращается в бардак.
KISS!
У меня уходит по полдня чтобы простое поле добавить и то после этого начинает отваливаться половина проекта в другом месте. А всего лишь можно было все решить в 1 SQOL + 10 строчек кода.
KISS!!!!!!!!!
Хороша вся эта абстракция, если ты один на проекте и знаешь каждый класс и каждый DTO. Когда не проекте 10 человек и больше и все начинают пилить эти самые абстракции получается жопа.
Типичной задачей для меня стало взять существующий функционал (все эти абстракции), получить данные, которые мне не подходят и после этого добавить еще 100500 строк чтобы поменять все под новые требования потому что лезть в то что уже существует страшно. Охрененный говнокод получается.
Вот Gres отличную архитектуру посоветовал - Microservices называется. Когда часть функционала инкапсулируется внутри сервиса и не зависит ни от чего вокруг. А общаются сервисы посредством определенного набора вызовов (API).
Вот так надо писать, это идеальная архитектура.
я и не усложняю. просто хорошо бы разобраться в теме.
так как наверняка сталкнемся с такой схемой позже, в чужих проектах.
нужно быть готовым. а пока сам не попробуешь - не поймешь.
ну и потом про ООП и разбивку кода на "слои". вот еще два год назад я покупал книги по програмированию на русском (чтоб быстрее читать), я сейчас только на английском, так как в какой то момент я почувствовал, что читать на английском удобнее, так как слова короче и яснее, и я уже в голове использую английские слова-термины-образы (по програмированию).
так и с ООП и "слоями". в какой то момент мы поймем, что так проще и быстрее...
ладно, не будем отвлекаться
