Инкапсуляция формой логики приложения Допустим, есть web-сайт, написанный на каком-либо языке программирования, использующий паттерн MVC. Все формы на сайте представлены объектами, публичными свойствами которых являются элементы формы, а методы позволяют произвести проверку формы на факт отправки, валидацию и т.д. Данные формы извлекаются из свойств, которые реализуют также рендеринг контролов, собственную валидацию, изменение состояния.
Вопрос концептуальный и состоит в том, где должна в этом случае располагаться логика приложения, например сохранение данных из формы в базу, – в контроллере или в самой форме, например как реализация метода onPostAndValidate, onValidateError(), etc. В случае обработки формы из контроллера возникает копирование логики обработки POST запроса для каждой формы. Если все инкапсулировать в форму, то возникает смутное сомнение в смешивании ответственности – не окажется ли перегруженым класс формы. Вот такая делема. Как посоветуете сделать?
Инкапсуляция формой логики приложения Допустим, есть web-сайт, написанный на каком-либо языке программирования, использующий паттерн MVC. Все формы на сайте представлены объектами, публичными свойствами которых являются элементы формы, а методы позволяют произвести проверку формы на факт отправки, валидацию и т.д. Данные формы извлекаются из свойств, которые реализуют также рендеринг контролов, собственную валидацию, изменение состояния.
Вопрос концептуальный и состоит в том, где должна в этом случае располагаться логика приложения, например сохранение данных из формы в базу, – в контроллере или в самой форме, например как реализация метода onPostAndValidate, onValidateError(), etc. В случае обработки формы из контроллера возникает копирование логики обработки POST запроса для каждой формы. Если все инкапсулировать в форму, то возникает смутное сомнение в смешивании ответственности – не окажется ли перегруженым класс формы. Вот такая делема. Как посоветуете сделать?
Вопрос концептуальный и состоит в том, где должна в этом случае располагаться логика приложения, например сохранение данных из формы в базу, – в контроллере или в самой форме, например как реализация метода onPostAndValidate, onValidateError(), etc. В случае обработки формы из контроллера возникает копирование логики обработки POST запроса для каждой формы. Если все инкапсулировать в форму, то возникает смутное сомнение в смешивании ответственности – не окажется ли перегруженым класс формы. Вот такая делема. Как посоветуете сделать?
Не можешь разобраться в этой теме?
Обратись за помощью к экспертам
Гарантированные бесплатные доработки
Быстрое выполнение от 2 часов
Проверка работы на плагиат
Интересные статьи из справочника
Поможем написать учебную работу
Отвечай на вопросы, зарабатывай баллы и трать их на призы.
Подробнее
Подробнее
В данной сиутации лучше всего будет инкапсулировать логику обработки формы в контроллере. Это позволит избежать дублирования кода при обработке POST запросов для каждой формы и обеспечит более четкое разделение ответственности между компонентами приложения.
Класс формы должен быть ответственен только за отображение и валидацию данных, а контроллер должен заниматься обработкой этих данных и их сохранением в базу данных. Таким образом, класс формы остается легким и легко поддерживаемым, а контроллер остается ответственен за бизнес-логику приложения.
В целом, важно следовать принципу единственной ответственности и разбивать функционал приложения на маленькие и независимые компоненты, чтобы облегчить поддержку и развитие приложения в будущем.