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

10

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ę?

Pritam Barhate
źródło
1
„Z drugiej strony wyciągnięcie wszystkiego z DB przy całkowicie zapełnionych modelach oznacza, że ​​jedna metoda służy wszystkim, ale to oczywiście da ci pewien narzut wydajności.” Naprawdę? Czy zmierzyłeś jakieś obciążenie ogólne związane z tą praktyką?
S.Lott,
>> Naprawdę? Czy zmierzyłeś jakieś obciążenie wynikające z tej praktyki? << - Tego się spodziewałem. Nie, nie mam. Ale byłoby ciekawie zmierzyć i w innym przypadku udowodnić, że się myli.
Pritam Barhate
Trudno udowodnić, że koszty ogólne nie istnieją. Możesz łatwo spierać się o wiele szczegółów, twierdząc, że pomiary nie są ważne w niektórych sytuacjach. O wiele ładniej jest, jeśli używasz „typowej” konfiguracji bazy danych, języka aplikacji itp. I profilujesz preferowaną konfigurację, aby pokazać, jakie są rzeczywiste koszty ogólne, abyśmy nie musieli sprzeczać się z różnymi czynnikami, które pominęliśmy w naszych pomiarach .
S.Lott,
1
Znalazłem świetny artykuł na temat ujawnienia modelu domeny w porównaniu z wysłaniem DTO na msdn.microsoft.com/en-us/magazine/ee236638.aspx .
Mayo

Odpowiedzi:

3

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”.


źródło
Dziękuję za odpowiedź. Sensowne jest stworzenie lite modelu w zależności od potrzeb. Ale czasem zastanawiam się, czy taka strategia nie stworzy zbyt wielu klas modeli? Zwłaszcza jeśli tworzę modele specyficzne dla widoków, a nie modele specyficzne dla logiki biznesowej.
Pritam Barhate
3

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.

Steve
źródło
2
>> Jeśli twój widok potrzebuje tylko 2 właściwości z modelu, masz zły model! << - Nie zawsze trzeba się martwić. Typowy przypadek pokazuje listę wyników wyszukiwania w aplikacjach biznesowych. Na przykład w CRM - kliencie - w większości na liście wyszukiwania będzie wyświetlana tylko nazwa i jedno lub 2 ważne pola. Ale CRM będzie miał wiele innych dziedzin związanych z tym klientem.
Pritam Barhate
1
Pytanie mówi, że w tym przypadku potrzebne są tylko 2 właściwości.
Steve
-2

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.

mefisto
źródło
PS, jeśli masz logikę bazy danych w modelu, spowoduje to wypchnięcie logiki biznesowej domeny do kontrolera.
mefisto
1
Jedna klasa, która wykonuje wszystkie operacje dla klientów, jest złym pomysłem, ponieważ będzie trudna do utrzymania.
Andy,