DRY vs Bezpieczeństwo i konserwacja w modelach MVC i View

Question

Lubię dążyć do DRY i oczywiście nie zawsze jest to możliwe. Muszę jednak podrapać się nad koncepcją, która wydaje się dość powszechna w MVC, czyli w "Modelu widoku".

Model widoku jest zaprojektowany tak, aby przekazywać do widoku tylko minimalną ilość informacji, zarówno pod kątem bezpieczeństwa, łatwości konserwacji, jak i problemów związanych z testowaniem. Rozumiem. To ma sens.

Jednak z perspektywy DRY model widoku po prostu powiela dane, które już posiadasz. Model widoku może być tymczasowy i używany tylko jako DTO, ale zasadniczo posiadasz dwie różne wersje tego samego modelu, co wydaje się naruszać zasadę DRY.

Czy modele widoku naruszają DRY? Czy są zło konieczne? Czy robią więcej dobrego niż złego?

Answer 1

Zostało to raz za razem. Nie tylko jest to dość istotne dupe, ale odpowiedź jest subiektywna i argumentująca. ViewModels są odpowiedzią na DDD i koncepcję uporczywej ignorancji.

Powiedzenie, że nie używamy ViewModels jest złe oznacza ignorowanie tego, że Django i Rails oraz większość frameworków PHP ORM/MVC nie dba o te koncepcje. Czy chcesz, aby ktoś powiedział ci te wszystkie inne języki i ramy "robią to źle?".

To, czy chcesz używać ViewModels, czy nie, zależy w 100% od tego, jakie style architektury wybierasz i jakie są cele aplikacji.

To jest tak, jakby pytaniem było przeciąganie i upuszczanie widoku GridView w aplikacji WebForm? Zależy od wielu rzeczy.

Istnieje również błędne przekonanie na temat SUSZENIA, które tu masz. Czy klasy proxy z usługi WCF naruszają DRY? Czy ViewModel zawiera logikę? Podstawowym celem DRY jest brak zduplikowanej logiki w sensownym celu. Czy kilka DTO, które współdzielą obiekty obiektów, naruszają to?

Polecenie DDD dla kontekstów ograniczonych może również służyć do dobrego odczytu. Jeśli obiekt ShoppingCart musi funkcjonować inaczej w ustawieniach magazynu a witryny e-commerce, czy to oznacza, że ​​chcesz udostępniać typy? Co się dzieje, gdy jedyną wspólną funkcją jest łączenie ceny (cena + podatek + dostawa)? Czy tworzysz klasę bazową właśnie dlatego, aby zwiększyć sprzężenie? Jakie są kompromisy w czasie/kosztach/utrzymaniu dla 100% SUCHA dla prostej metody, takiej jak GetTotal(). Czy naruszanie DRY, gdy ma to sens, faktycznie zmniejsza złożoność i ogólny koszt utrzymania twojego kodu?

Przykro mi z powodu odpowiedzi na tak wiele pytań, ale mam nadzieję, że teraz możesz zobaczyć niuanse i zawiłości zadawanego pytania. ;)

Answer 2

Można również zauważyć, że niestosowanie modeli widoków stanowiłoby naruszenie zasady jednej odpowiedzialności - Twój podmiot nie powinien być zanieczyszczony problemami interfejsu użytkownika.

Uważam również, że prawdziwa wartość modeli widoku niekoniecznie musi być widoczna w wersji 1.0 aplikacji. Będziesz sobie wdzięczny, pracując nad wersją 2.0, gdy całkowicie pomyślisz o tym, jak działa twój back-end, ale nie musisz przenosić tych zmian do warstwy widoku.