MVC: Повністю заселені моделі або частково заповнені моделі?

Цей так довго переслідував мене. Як ви робите програмування MVC, на вашу думку, це найкраща практика програмування? Чи варто використовувати повністю заселені моделі або частково заповнені моделі, особливо коли я знаю, що для цього конкретного завдання мені знадобляться лише 2 поля від об'єкта моделі, у якого є 5 інших?

Іноді просто здається злочинним заповнення списку з 20 модельних об'єктів усіма значеннями з бази даних, коли ви знаєте, що вам знадобиться лише декілька з них.

Звичайно, часткова модель означає, що вам доведеться записати ще один метод у свій DAO, крім того, який отримує все. Що означає більше коду для підтримки?

З іншого боку, витягнути все з БД із повністю заселеними моделями означає, що один метод служить усім, але це, очевидно, дасть вам високу ефективність роботи.

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

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

У вас є два варіанти:

1) Залиште деякі поля в моделі незаповненими

2) Створіть додаткову «легку» модель для вашої конкретної ситуації

Кого вибрати, залежить знову від двох речей:

а) Скільки полів "повної" моделі буде проігноровано

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

Якщо є лише кілька і більше полів, які можна заповнити, добре перейти з 1).

Якщо б) є лише винятковою індивідуальною ситуацією, можливо, немає сенсу створювати додаткову модель лише для одного випадку використання.

Інший підхід полягає у визначенні моделі "lite" та успадкуванні від неї "повної" моделі.

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

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

Однак, якщо ви в основному вибираєте кілька додаткових полів із таблиці або перегляду, тоді вартість отримання додаткових даних до всіх намірів і цілей дорівнює нулю (ОК, на провід є більше байтів, але найбільші витрати, ймовірно, є бути у створенні та розриві з'єднання), тому, якщо є шанс, вам знадобляться додаткові дані, я б, ймовірно, повністю заповнив модель, як тільки ви щасливі, що ви маєте потрібну модель .

Обладнання дешеве, але жодна кількість обладнання не може привести до поганого дизайну.

Модель - це не DAO.

І інша річ: якщо ви говорите, що у вас є 20 моделей (клієнти, зі свого прикладу), то це не модель MVC. Модель домену не відображається безпосередньо в одному рядку таблиці. Натомість він повинен відповідати за всі операції, здійснені з вашими "замовниками".

У вашому прикладі "Клієнт" - це не доменна модель, а просто об'єкт всередині моделі.

Що стосується взаємодії з базою даних, то ця відповідальність повинна бути делегована об’єкту картографії даних , який повинен знати, як зберігати та отримувати ваші екземпляри класу клієнтів.