Должны ли объекты модели быть гибкими

[Извините, но работа является собственностью, поэтому я не могу дать подробную информацию об объектах]

Я работаю над Java-приложением с коллегой. Я делаю клиентскую часть, а он пишет серверный код.

Приложение отображает таблицу объектов X. В столбцах таблицы показаны некоторые атрибуты X. Кроме того, у нас есть столбец, который показывает количество Y для каждого X. (Ассоциация Y к X много к одному, и в одну сторону Y имеет ссылку на своего родителя X).

Счетчик Y не является атрибутом X, а получается через запрос в БД.

Я использую TableModel, поэтому, очевидно, было бы проще использовать объекты X в качестве модели для таблицы. Но поскольку счетчик Y не является атрибутом X, мне нужно будет создать объект-контейнер для хранения X плюс счетчик. Это довольно раздражает, так как добавляет класс, который кажется ненужным.

Я предложил своему коллеге добавить в X дополнительное поле плюс геттер:

private void Информация о карте = new HashMap();

Это сделало бы объекты модели X более гибкими. Я могу сохранить любое состояние, которое мне нужно, в любое время в клиенте, не затрагивая основные атрибуты модели, которые специфичны для природы X. Ключи будут определены только в клиенте, чтобы модель не загрязнялась.

Он отказался, потому что считает, что объекты модели должны моделировать только домен, а дополнительное поле не связано с объектами домена и поэтому не должно добавляться. Он считает, что с этим должен справиться клиент.

Обе точки зрения, похоже, заслуживают внимания, поэтому мне было бы интересно, что другие читатели думают/чувствуют по этому поводу.

Спасибо,

Тим


java model model-view-controller datamodel
person Timothy Mowlem    schedule 14.09.2010    source источник

Ответы (3)


arrow_upward
3
arrow_downward

Я думаю, вы путаете модель базы данных с моделью в MVC. Имейте в виду, что шаблон MVC — это шаблон проектирования для уровня представления. Модель, т. е. в MVC, может быть моделью базы данных (сущности в базе данных) в упрощенном приложении, но это не обязательно.

Я считаю, что у вас должен быть отдельный класс (модель таблицы), как вы сказали, который должен содержать поля, которые вы отображаете в таблице. Эта модель будет заполняться из уровня бизнес-логики, т. е. должна быть результатом вашего BLL. Вы также можете назвать это DTO (объект передачи данных). Идея состоит в том, чтобы иметь только те данные, которые вам нужны. Если вам нужен подсчет, то используйте только подсчет в DTO, а не все Y. Это не только сделает ваше приложение управляемым, но и уменьшит передачу данных, чем происходит между слоями, что уменьшит объем памяти вашего приложения и увеличит производительность также.

person Faisal Feroz    schedule 14.09.2010
comment
Хорошо сказано. Я видел много людей, использующих MVC в качестве шаблона для всех слоев приложения (что является неправильным представлением). - person Faisal Feroz; 14.09.2010

arrow_upward
1
arrow_downward

Я точно в таком же положении (в основном я серверный парень), и я вижу это так же, как и ваш коллега.

В нашем случае серверная часть — это веб-сервис. Вы никогда не знаете, кто будет звонить в службу в будущем, поэтому я хочу, чтобы она была как можно более общей. Всякий раз, когда нам нужны специальные данные в модели, мы расширяем соответствующие классы и добавляем их таким образом. Часто это несложно, поскольку нам все равно нужно создавать подклассы (например, нам нужно PropertyChangeSupport во многих классах для MVC).

Однако я не знаю, решает ли это ваш пример «счета». Мы также столкнулись с похожей ситуацией, и я только что создал специальный DTO как user446612 предполагает, что держит данные.

person musiKk    schedule 14.09.2010

arrow_upward
0
arrow_downward

Спасибо за ответы, ребята.

Тингу сказал:

Я думаю, вы путаете модель базы данных с моделью в MVC.

Хорошо, да. Итак, вы говорите, что фактически существует два разных объекта модели, один для базы данных и один для M в MVC в клиентском приложении, и что модель на стороне клиента заполняется BLL из извлеченных объектов модели базы данных?

musiKk говорит то же самое, судя по моему чтению.

Мы используем модель на стороне сервера в качестве модели данных (MVC M) в клиенте, и объекты просты.

musiKk назвал следующую причину:

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

Именно такой аргумент выдвинул мой коллега. Я полностью согласен, что это необходимо. Однако моя мысль заключалась в том, что добавление карты объекта в модель никоим образом не делает модель менее общей. Она предоставляется для удобства клиента и представляет собой пустую карту.

Преимущества:

(1) избавляет клиента от необходимости создавать подклассы или создавать новые объекты для простого случая, подобного этому, с одним дополнительным полем

(2) очень гибкий, поскольку переходное состояние может быть инкапсулировано с объектом, поскольку оно используется в клиенте

Недостатки:

(1) объекты больше, что делает их больше при перемещении по сети

(2) если вы подкласс, у вас есть дополнительное поле, даже если вы его не используете

person Timothy Mowlem    schedule 14.09.2010
comment
Вы должны обновить свой вопрос, если есть изменения. СО это не форум. Вы разместили свое обновление в качестве ответа. - person musiKk; 14.09.2010