пытался использовать MVC паттерн при построении отчётов на ЛБД?
ну если на локальных классах - то проблем возникнуть не должно
а насколько плох будет подход если я сделаю GET в репорте и контроллером передам уже все таблицы ЛБД в инициализацию модели на глобальном классе?
ну типа смысл половину сбора данных выставлять в одно место, а вторую в другое - просто чтобы реализовать паттерн и из-за чего понимание логики работы для других людей будет затруднено
на самом деле транзакционный подход к программам в сапе уже сам по себе поднимает вопрос о том, как к этому прикручивать mvc. Можно конечно в каждой программе на классах крутить своё mvc, но это оверкил для 80% программ. Самый минимум - это выносить модель(ну или data access layer), чтобы при необходимости можно было бы этот слой вынести/использовать в другом месте. А логика по выводу всего этого добра в каждой программе - скорее всего штучная вещь, накручивать там дополнительные абстракции зачастую нет смысла.
на самом деле я раньше тоже так думал, а как стал везде пихать mvc стало легче потом сопровождать
я потому в отчетах логику в глобальные классы и не выношу, смысла нет вообще, по mvc - тут когда-то пробигала ссылка, где расписали что по тому как отчет построен изначально проще и выгоднее ерализовать через паттерн AV - где есть класс application который отвечает за сбор данных и реагирования на события отчетов и класс view для отображения
тут вот вопрос, зачем выносить отдельный view, если условный salv или cl_gui_alv_grid уже можно сказать и есть вью
там просто уже филдкаталог построить, события навешать и тд. код который чисто к отображения относится
день ООП в чатеке был вчера.... невовремя ты срачЪ поднял :)
вчера я коврял ассинхронные WF Events
повесь себе над рабочим местом расписание чатега!
я между прочим перед задаванием своего нубского вопроса заранее извинился
Обсуждают сегодня