Walidacja oraz w warstwie usługi lub obiektach biznesowych?

Question

Martin Fowler suggests używanie warstwy usługi jako granicy między modelem domeny a "Ładowanie danych". Jednak Rockford Lhotka sugeruje budowanie walidacji w samym obiekcie biznesowym i właśnie to robi CSLA.NET.

Korzyści z abstrahowania tego w warstwę usługową jest oczywiście to, że warstwa usług może koordynować działanie/działanie w wielu obiektach biznesowych. Ale jakie są inne wady i zalety używania warstwy usługi bezpośrednio przy użyciu obiektów biznesowych do logiki biznesowej i sprawdzania poprawności?

Answer 1

Jestem zdecydowanie w obozie Rocky Lhotka. Uważam, że obiekty biznesowe powinny być bardzo łatwe do "przenoszenia" między aplikacjami i warstwami interfejsu użytkownika. Dodanie dodatkowej "warstwy usług" najprawdopodobniej doda zależność do twoich obiektów, przez co stanie się mniej "przenośna".

Po poprawnym napisaniu struktury obiektu biznesowego obiekty biznesowe powinny być w stanie prawidłowo obsłużyć weryfikację między różnymi obiektami biznesowymi. CSLA.NET robi to poprawnie poprzez posiadanie relacji rodzic/dziecko, jak również koncepcję unieważnienia poprawności właściwości.

Answer 2

Nie jestem pewien, czy to wymyśliłeś.

Sugerowana przez Martina Fowlera w PEAA warstwa usługi to interfejs API między interfejsem użytkownika (lub klientami) a warstwami domeny/danych. ujawni wszelkie funkcje, które mogą być wykorzystane przez klienta.

Jeśli spojrzeć na model domeny (Here)

modelu obiektu domeny, która obejmuje zarówno zachowania i dane.

Domain tier będzie zawierać te obiekty, które będą miały actions/walidacji (zachowanie) i państwowych (dane)

Obiekty te mogą być ponownie wykorzystane w innych aplikacjach, będzie również zależała od projektu. warstwa domeny nie powinna być zależna od warstwy usługi

Biorąc pod uwagę, że obiekty Domen mają zachowanie (dotyczy to sprawdzania poprawności) i danych. Warstwa serwisowa jest tym, co chcesz, aby Twoja aplikacja eksponowała (do funkcji funkcjonalnej). IE dodać klienta lub konto, calcualte rachunki na koniec miesiąca.

Wystarczy popatrzeć na układ ostry architure za (http://www.sharparchitecture.net/)

To jest moje rozumienie tego meterial.

HTH

kości

Answer 3

szukam bardziej elastycznego modelu domeny, gdzie jest rozdzielenie danych i zachowanie, ale nie wierzę Layer Service jest odpowiednia warstwa za zachowanie . Zamiast tego, być może, można zastosować prostą metodę Business Logic Layer, w której obiekty obiektu biznesowego eksponują tylko dane, a obiekty procesów biznesowych ujawniają tylko zachowanie, a wśród tych zachowań są metody sprawdzania poprawności.

Jedną z korzyści, w zależności od luźnego powiązania procesów biznesowych, można zastosować walidację w szerszym zakresie kowariantnych, a nawet niezmiennych typów.Zastanów się przez chwilę nad weryfikacją pól "FirstName" i "LastName", a następnie rozważ, czy te pola mogą w dowolnym dużym systemie istnieć w kilku lub kilku różnych jednostkach. Oddzielenie procesu od danych umożliwiłoby jednorazowe wdrożenie procesów sprawdzania poprawności i zastosowanie ich do wielu obiektów, które zapewniają te same dane.

Zauważyłem, że ideał, że Model Domen "powinien" składać się z Obiektów Domeny będących połączeniem Danych i Zachowania to koncepcja Fowlera/Evansa, około 2000-2002 (krótko po szybkiej migracji w kierunku rozproszonych systemów informacyjnych zamiast aplikacji dwuwarstwowych.)

Myśli?