Dobre praktyki unikania powielania sprawdzania poprawności logiki podczas pracy z obu obiektów domeny i widoków modeli w ASP.NET MVC

Question

wspólne scenariusz:

hierarchiczną modelu domeny jest odwzorowywany na płaskiej modelu widoku dla celów prezentacyjnych.

Mam pełną konfigurację sprawdzania poprawności w mojej domenie i chciałbym uniknąć odwzorowania modelu widoku na obiekt domeny tylko po to, aby dowiedzieć się, że niektóre właściwości są nieprawidłowe. Nie chcę też duplikować logiki sprawdzania poprawności w moich modelach widoku.

Jakie są tutaj dobre praktyki?

Jestem przeciwko interfejsom zarówno dla modeli widoków, jak i obiektów domen, ponieważ modele widoku są zwykle ciągliwe i płaskie, podczas gdy obiekty domeny są często zagnieżdżane i mają wiele innych typów danych dla właściwości.

Zastanawiam się nad jakimś wtykowym walidatorem, który będzie wystarczająco inteligentny, aby zweryfikować oba obiekty domeny i wyświetlić modele, ale nieco sceptycznie podchodzi do implementacji.

Ale dla uproszczenia jestem pochylony w kierunku takiego podejścia: Walidacja strona

Server zdarza się tylko w modelu domeny; modele widoku nie są sprawdzane, ale dane są sprawdzane na kliencie za pomocą JavaScript. Dlatego w większości przypadków moje modele widoków będą ważne, a logika walidacji pozostanie w jednym miejscu i będzie występować tylko w modelu domenowym. Takie podejście ma tę wadę, że sprawdzanie poprawności mVc 2 w asp.netu nie będzie w stanie go obsłużyć. Co myślisz?

Dzięki.

Answer 1

Biblioteka Microsoft Enterprise oferuje taką bibliotekę "Pluggable Validation", która opiera się na składnikach generycznych, jeśli obsługuje pamięć.

Nie podoba mi się sposób, w jaki zadziałało, nie wspominając już o liczbie zależności od innych komponentów EL, ale nadal może być wart obejrzenia.

Nie jestem ekspertem w tej dziedzinie, ale jestem głęboko przekonany, że dane powinny być zatwierdzone tuż przed tym, jak chcesz coś z nim zrobić i ZAWSZE zanim przejdziesz do swojego repozytorium. Dlatego najlepszym miejscem dla Twojej Logiki Walidacyjnej jest Twoja Warstwa Logiki Biznesowej. Walidacja po stronie klienta, choć przyjemna dla użytkownika, sprawia, że ​​utrzymanie kodu jest koszmarem, a także powoduje duplikację kodu, co może powodować problemy w dalszej części.

Twoje obiekty prezentacji powinny być, moim zdaniem, DTO.Kiedy użytkownik przesyła dane z powrotem do kontrolerów (i BLL), można użyć parserów do przekształcenia obiektów prezentacji w obiekty biznesowe, które następnie można sprawdzić.

Polecam lekturę bloga Rudy'ego Lacovary (zwanego także The Angry .NET Developer). Jest bardzo skromnym facetem, który ma wiele dobrych rzeczy do powiedzenia na takie tematy.

HTH

Answer 2

There is no validation approach that fits always.

W twoim przypadku użyłbym sprawdzania poprawności mvc2 (z walidacją klienta) i wróciłem do sprawdzania poprawności domeny, jeśli przejdzie weryfikacja viewmodel.

Answer 3

Podoba mi się pomysł walidatorów z wtyczkami/wstrzykiwaniem. Tak zazwyczaj robię sprawdzanie poprawności (bez względu na to, czy są to formularze internetowe, mvc, wpf itp.). Czemu? Ponieważ zasady sprawdzania poprawności różnią się w zależności od scenariusza i warstwy aplikacji. Przykład: Twój model widoku może mieć pewne reguły sprawdzania poprawności, które wynikają z układu interfejsu użytkownika, a nie z reguł domeny lub infrastruktury. Jeśli uczynisz reguły i walidatory w kompozycie, możesz ponownie użyć wielu reguł ograniczeń danych w każdym warstwie/scenariuszu.

Chociaż uważam, że sprawdzanie poprawności Javascript sprawia, że ​​rzeczy są zgryźliwe dla użytkownika, byłbym nieufny tylko przy użyciu javascript w VM.