Przymierzam się do zrobienia pewnej aplikacji internetowej. Zakładam użycie MVC i takie tam.
Zastanawiam się nad tym, czy obiekty pochodzące z ORM powinny być dostępne w widokach, czy należałoby zrobić jakieś pośrednie klasy DTO, które byłyby mapowane gdzieś na styku DAL z warstwą logiki biznesowej, a dalej, gdzieś chyba w kontrolerach z tych DTO byłyby składane ViewModele przekazywane do widoków. Chodzi mi z jednej strony o to, żeby nie przekazywać nigdzie niepotrzebnych danych, a z drugiej strony nie narobić się za bardzo (3 klasy na jedną encję tworzy jednak trochę kodu).
Jeszcze jedna rzecz mnie nurtuje - bo np. na liście pracowników wyświetla się tylko imię i nazwisko, a w szczegółach także jego adres. Czy w takim razie dobrze jest robić oddzielne klasy dla każdego możliwego widoku jakiejś encji?
Jak byście to zrealizowali? Jak robicie w swoich projektach?
Pracownik posiada adres(y). Zawsze staram się rozklepać obiekt na mniejsze. Z dwóch powodów. Po pierwsze łatwiej jest reagować na zmiany. Co będzie jak poza adresem zameldowania będzie jeszcze adres korespondencyjny i adres dostawcy pizzy? Dodawanie kolumn w bazie to kiepski pomysł. A tak tylko zmieniasz pojedyncze pole na listę i po problemie.
Po drugie mając wiele obiektów reprezentujących proste dane nie musisz kilkukrotnie pisać podobnego kodu. Przykładowo adresy dostawy mogą być tak samo obsługiwane jak adresy pracowników i nie musisz pisać nowych walidacji itp.
Co ciekawe kiedyś na warszawskiej DPG rozważaliśmy czy opłaca się wyrzucać do osobnych klas np. wiek i doszliśmy do wniosku, że nie jest to zły pomysł ponieważ można znacznie łatwiej tworzyć nowe klasy mając taką bibliotekę komponentów. Do tego zazwyczaj masz też walidatory, parsery itp.
Może niejasno się wyraziłem, ja nie pytam o to jak zamodelować dziedzinę problemu i co powinno, a co nie powinno być oddzielną encją. To powiedzmy umiem zrobić, śmiem twierdzić, że nawet lepiej niż niektórzy znani mi analitycy.
Pytam o tworzenie wielu klas dla jednej tabeli działających między różnymi warstwami aplikacji. DAL <- 1 klasa encji -> Logika biznesowa <- 2 klasa encji -> kontroler <- 3 klasa encji -> widok. Pytam także o tworzenie oddzielnych klas dla różnych widoków (lista, szczegóły pozycji, edycja, itd.)
Chodzi o klasy, które udostępniają różne atrybuty w zależności od tego gdzie są wykorzystywane.
W ten deseń... to raczej nie. Chyba, że technologia wymaga jakiś klas transportowych (vide GWT) względnie jeżeli wybranie jakiś danych będzie długotrwałe albo obciąży serwer (duże obrazki, długie teksty). W przeciwnym wypadku to tylko dołożysz sobie kodu do utrzymania.