Atrybuty sprawdzania poprawności ASP.Net Web API na DTO?

Question

Używam ASP.Net Web API i Code First Entity Framework iz tego, co przeczytałem, zazwyczaj ujawniasz obiekty DTO, a nie obiekty encji bezpośrednio w twoich metodach działania (zgodnie z http://www.asp.net/web-api/overview/data/using-web-api-with-entity-framework/part-5).

Tak więc w jednym przypadku nad którym pracuję, aby uniknąć problemu "over-posting", jak opisano w powyższym linku, utworzyłem obiekt DTO z niemal wszystkimi właściwościami, co obiekt modelu. Zastanawiam się jednak, czy muszę duplikować wszystkie te same zestawy atrybutów sprawdzania poprawności (np. [Wymagane], [Zakres (N, M)] ​​itp. Zarówno dla właściwości DTO, jak i modelu? Początkowo miałem nadzieję, że nie do (w celu uniknięcia powielania), ale potrzebujesz atrybutów sprawdzania poprawności w DTO, jeśli chcesz skorzystać z walidacji wiążącej (np. ModelState.IsValid) i na modelu głównym, jeśli chcesz utworzyć bazę danych z odpowiednimi ograniczeniami ([Wymagane ] -> nie null, itd.)

Czy nie ma lepszego sposobu

Ponadto, istnieją pewne cechy, które używa Entity ale walidacja wiążący model nie używają Na przykład, gdy [Range (n? , m)] będzie wyraźnie wpływać na walidację na niektórych danych wejściowych klienta, czy podmiot w ogóle o to dba (nie ma wpływu na utworzony DB schemat z tego, co mogę powiedzieć?)

Answer 1

Podmioty powinny mieć tylko te atrybuty, które rzeczywiście mają wpływ na bazę danych. DTO nie powinny mieć żadnych atrybutów do sprawdzania poprawności, z wyjątkiem obiektu DataMemberAttribute w celu zdefiniowania, czy właściwość jest wymagana i w jakiej kolejności powinna być wyświetlana itd. W przypadku OData należy również ustawić wartość KeyAttribute. Modele powinny mieć atrybuty sprawdzania poprawności. Ponieważ DTO i modele są prawdopodobnie prawie identyczne, które tworzysz dla każdego dto, który wymaga sprawdzenia poprawności modelu i po prostu zamienia wartość dto na obiekt modelu. Teraz można go zatwierdzić, jeśli nie używasz ValidationAttributes dla modeli można potwierdzić je na przykład z FluentValidation

Więc krótko mówiąc:

• Podmioty dostać tylko atrybuty, które faktycznie mają wpływ schematu bazy danych za

• DTOs są proste obiekty bez logiki walidacji, z wyjątkiem DataMemberAttribute

• modele powinny mieć sprawdzania poprawności atrybutów (onl y w razie potrzeby, nie potrzebne przy korzystaniu FluentValidation)

Workflow dla POST będą: -> DTO przychodzi -> Zmienne dto od modelu -> walidacji modelu -> Model swap do podmiotu -> Store podmiot w bazie danych -> Użyj zaktualizowaną podmiot i zamienić go na nowy DTO -> Zwraca Dto

Pozdrowienia, Voltaic