MVC: полностью заполненные модели или частично заполненные модели?

Этот преследовал меня так долго. Когда вы занимаетесь программированием MVC, что вы считаете лучшей практикой программирования? Следует ли использовать полностью заполненные модели или частично заполненные, особенно когда я знаю, что для этой конкретной задачи мне понадобятся только 2 поля из объекта модели, который имеет 5 других?

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

Конечно, частичная модель означает, что вам придется написать еще один метод в вашем DAO, кроме того, который выбирает все. Что означает больше кода для поддержки?

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

Я вижу, что ORM (например, Hibernate или ActiveRecord of Rails) одобряет тенденции в программировании MVC, а базы данных, такие как полные модели Google BigTable, является принятой тенденцией. Но что, если вы все еще используете старый добрый JDBC?

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

У вас есть два варианта:

1) Оставьте некоторые поля в модели незаполненными

2) Создайте дополнительную «облегченную» модель для вашей конкретной ситуации

Какой из них выбрать, снова зависит от двух вещей:

а) Сколько полей "полной" модели будут игнорироваться

б) Как часто эта «облегченная» модель будет создаваться

Если есть только пара или более полей, которые могут быть незаполнены, можно перейти к 1).

Если b) является исключительно исключительной индивидуальной ситуацией, возможно, нет смысла создавать дополнительную модель только для одного варианта использования.

Другой подход заключается в определении «облегченной» модели и наследовании от нее «полной» модели.

Если вашему представлению нужны только 2 свойства из модели, то у вас (вероятно) неправильная модель для этого варианта использования! Я хотел бы создать модель, соответствующую виду, сохранить дополнительные поиски в БД и заполнить только те данные, которые вам нужны. Если последующее представление требует более подробной информации, то вам нужно спросить, получить ли я дополнительные данные позже, или я должен получить все это заранее ...

В качестве альтернативы вы можете взглянуть на какую-то ленивую оценку, поэтому значения заполняются, когда они вам нужны. Это может хорошо работать, но, очевидно, требует больше работы и может привести к многократным обращениям к БД, что не очень хорошо, если вы в конечном итоге делаете это много.

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

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

Модель не является DAO.

И еще: если вы скажете, что у вас 20 моделей (по вашему примеру, клиенты), то это не модель MVC. Модель предметной области не отображается напрямую в одну строку таблицы. Вместо этого он должен нести ответственность за все операции, выполняемые с вашими «клиентами».

В вашем примере «Клиент» - это не модель предметной области, а просто объект внутри модели.

Что касается взаимодействия с базой данных, эта ответственность должна быть делегирована объекту отображения данных , который должен знать, как хранить и извлекать ваши экземпляры класса Customer.