MVC: Modele w pełni zaludnione czy częściowo wypełnione?

Ten tak długo mnie prześladuje. Jak myślisz, wykonując programowanie MVC, lepszą praktykę programowania? Czy należy używać modeli w pełni wypełnionych lub częściowo wypełnionych, zwłaszcza gdy wiem, że do tego konkretnego zadania będę potrzebował tylko 2 pól z obiektu modelu, który ma 5 innych?

Czasami wypełnianie listy 20 obiektów modelowych wszystkimi wartościami z bazy danych wydaje się zbrodnicze, gdy wiesz, że będziesz potrzebować tylko kilku z nich.

Oczywiście model częściowy oznacza, że ​​będziesz musiał napisać jeszcze jedną metodę w DAO oprócz tej, która pobiera wszystko. Co oznacza więcej kodu do utrzymania?

Z drugiej strony wyciąganie wszystkiego z DB przy całkowicie zapełnionych modelach oznacza, że ​​jedna metoda obsługuje wszystko, ale oczywiście da ci to pewien narzut wydajności.

Widzę, że ORM (takie jak Hibernacja lub ActiveRecord z Rails) faworyzuje trendy w programowaniu MVC i bazach danych, takich jak pełne modele BigTable Google, jest trendem akceptowanym. Ale co, jeśli nadal używasz starego, dobrego JDBC?

Sprzęt jest tani, rozwój jest kosztowny. Czy to prawda, nawet jeśli aplikacja wymaga skalowania do kilkuset tysięcy żądań na godzinę?

Masz dwie opcje:

1) Pozostaw niektóre pola w modelu niewypełnione

2) Utwórz dodatkowy model „lite” dla konkretnej sytuacji

Który z nich zależy ponownie od dwóch rzeczy:

a) Ile pól modelu „pełnego” zostanie zignorowanych

b) Jak często ten „lite” model będzie tworzony

Jeśli jest tylko kilka pól, które mogą być wypełnione, możesz użyć 1).

Jeśli b) jest wyjątkową indywidualną sytuacją, być może nie ma sensu tworzenie dodatkowego modelu tylko dla jednego przypadku użycia.

Innym podejściem jest zdefiniowanie modelu „lite” i odziedziczenie po nim modelu „pełnego”.

Jeśli twój widok potrzebuje tylko 2 właściwości z modelu, to prawdopodobnie masz niewłaściwy model dla tego przypadku użycia! Chciałbym stworzyć model dopasowany do widoku, zapisać dodatkowe wyszukiwania DB i wypełnić tylko potrzebne dane. Jeśli kolejny widok wymaga więcej szczegółów, musisz zapytać, czy otrzymam dodatkowe dane później, czy powinienem to wszystko uzyskać z góry ...

Alternatywnie możesz spojrzeć na jakąś leniwą ocenę, więc wartości są wypełniane, gdy ich potrzebujesz. Może to działać dobrze, ale jest oczywiście więcej pracy i może skończyć się wielokrotnymi podróżami do DB, co nie jest świetne, jeśli skończysz dużo.

To powiedziawszy, jeśli w zasadzie wybierasz kilka dodatkowych pól z tabeli lub widoku, wówczas koszt uzyskania tych dodatkowych danych jest zerowy dla wszystkich celów i celów (OK, jest więcej bajtów na linii, ale największe koszty są prawdopodobne podczas tworzenia i rozłączania połączenia), więc jeśli istnieje szansa, że ​​będziesz potrzebować dodatkowych danych, prawdopodobnie zapełnię model w pełni, gdy będziesz zadowolony, że masz odpowiedni model .

Sprzęt jest tani, ale żadna ilość sprzętu nie może sprawić, że zły projekt będzie działał dobrze.

Model nie jest DAO.

I jeszcze jedno: jeśli powiesz, że masz 20 modeli (klientów, z twojego przykładu), to nie jest to model MVC. Model domeny nie mapuje bezpośrednio na pojedynczy wiersz tabeli. Zamiast tego powinien być odpowiedzialny za wszystkie operacje wykonywane z „klientami”.

W twoim przykładzie „Klient” nie jest modelem domeny, ale tylko obiektem wewnątrz modelu.

W przypadku interakcji z bazą danych odpowiedzialność tę należy przekazać do obiektu odwzorowującego dane , który powinien wiedzieć, jak przechowywać i pobierać instancje klasy Customer.