Должен ли POJO быть подключен к представлению или контроллеру?

Question

Я работаю над проектом Spring, где общая структура основана на макете view-controller-service-layer-layer-DAO / POJO.

Я работаю над новым объектом POJO и не уверен, где будет лучшее место для его привязки. Два из них, которые имеют для меня наибольшее значение, - это поместить их в представление, где они используются, или контроллер, который добавляет их в представление так же, как и другие фрагменты данных.

В одном представлении есть таблица, которая отображает несколько видов похожих данных. В таблице показано имя данных, количество изменений для новых, измененных и удаленных частей данных (которые можно детализировать) и, наконец, общее количество изменений.

Поскольку я рассчитываю самостоятельно поддерживать это программное обеспечение в будущем, я постарался сделать его расширяемым и простым в обслуживании. Поскольку проекту требуются двуязычные страницы, я активно использую функцию обмена сообщениями весной. Так что мой новый объект принимает 5 параметров. Первые четыре параметра - это строки, ключ сообщения пружины имени поля, ключ сообщения пружины заголовка страницы детализации, имя хранимой процедуры базы данных для счетчиков и имя хранимой процедуры базы данных для значений страницы детализации. Последний параметр - это список массивов строк, которые являются ключами обмена сообщениями для заголовков столбцов на странице детализации.

Используя объект, я должен иметь возможность касаться только одного файла, когда я хочу добавить или удалить значения из этой таблицы, без необходимости изменять несколько страниц. Что я не понял, так это то, как правильно его использовать. Было бы более уместно, если бы вызов вызывал / создавал объект и для каждого элемента создавал для него список таблиц, или если бы контроллер вызывал / создавал объект и добавлял данные к объекту представления, было бы более уместным?

То, как я построил новый POJO, нарушает модель vcsd, которая используется для проекта, но я не хотел создавать дополнительные файлы проекта для взаимодействия с объектом, который используется только для отображения в этой одной таблице, и углубиться в результаты из этой таблицы. Если бы я собирался иметь больше взаимодействий с объектом, то сервисный уровень, предлагающий богатый список взаимодействий, мог бы быть полезным. Но в этом случае POJO в значительной степени самодостаточен, поскольку имеет тесно связанный DOA для вызовов своей собственной базы данных.

Answer 1

Вопрос довольно широкий, чтобы ответить одним утверждением, поэтому я рассмотрю все ключевые части.Сначала я отвечу на сам вопрос заголовка:

Должен ли POJO быть подключен к представлению или контроллеру?

POJO никогда не подключается к представлению или контроллеру.Это независимая структура данных, пакет данных для любой библиотеки, инфраструктуры или компонентов (таких как view или controller).Идея состоит в том, что эта модель должна быть разделена между представлениями и контроллерами.Подробнее о POJO на Spring: Понимание POJO .

Таким образом, мой новый объект принимает 5 параметров.

Разлагает объекты на меньшие и использует декоратор , чтобы добавить им функциональность или состояние.

Используя объект, я должен иметь возможность касаться только одного файла, когда я хочу добавить или удалить значения из этой таблицы, без необходимости изменять несколько страниц.Что я не понял, так это то, как правильно его использовать.Будет ли более подходящим иметь вызов view / создать объект и для каждого элемента создать список для него или иметь вызов контроллера / создать объект и добавить данные к объекту view?

1-1 абстракция файла и объекта в порядке.Создайте объект как неизменяемый, и пусть источником данных будет только файл.Выполните действия добавления, обновления и удаления с помощью методов, которые касаются источника источника данных - файла.Все же объект остается неизменным, который является ключом для ремонтопригодности.List<MyObject> хорошо представлял бы таблицу.

Если бы у меня было больше взаимодействий с объектом, то сервисный уровень, предлагающий богатый список взаимодействий, мог бы быть полезен.

По этой причине был введен уровень обслуживания.