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

Question

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

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

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

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

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

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

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

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

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

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

Спасибо

Тим

Answer 1

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

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

Answer 2

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

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

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

Answer 3

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

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

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

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

musiKk говорит то же самое в моем чтении.

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

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

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

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

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

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

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

Недостатки:

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

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