Czy obiekt modelu domeny przechodzi między warstwami narzutów?

Question

Pracuję nad projektem wykorzystującym hibernację i wiosnę. Hibernacja jest hermetyzowana w warstwie DAO, a warstwa DAO ma również odpowiednią warstwę usługi, a także kontrolery odwzorowane na żądania i strony JSP. Powiedziano mi, żeby nie przekazywać obiektów między tymi warstwami (Kontrolery < -> Service < -> DAO), ponieważ jest to obciążenie wydajnościowe. Jedna konkretna sytuacja polegała na tym, że gdy potrzebowałem zaktualizować wartość logiczną w obiekcie domeny (klasie ORM), napisałem metodę, która przekazała obiekt domeny między warstwą usługi a warstwą DAO, i powiedziano mi, aby przekazał identyfikator obiektu i konkretną wartość logiczną tylko wartość i napisać osobne metody w warstwach dla tego. Czy to jest poprawne? Czuję, że spowoduje to unieważnienie wielu zalet korzystania z narzędzia ORM (Hibernacja). Czy nie mam racji? Wszelkie porady i spostrzeżenia będą przydatne ...

Answer 1

Masz 100% racji. To straszna rada. Przekaż obiekty dookoła. Jest to dokładnie to, do czego został zaprojektowany Hibernate, a "obciążenie związane z wydajnością" w przypadku normalnego przekazywania obiektów jest po prostu szalone. O ile w aplikacji nie ma czegoś, czego nie znasz, bądź ostrożny w stosunku do osoby, która ci to powiedziała.

Answer 2

Podobnie jak w przypadku większości problemów związanych z architekturą, istnieje tu kompromis.

W przypadku aplikacji, które nie przewidują korzystania z architektury zorientowanej na usługi (np. Samodzielna strona internetowa z bazą danych, pojedynczą wewnętrzną aplikacją biznesową), znacznie lepiej jest, aby model domeny był widoczny na wszystkich warstwach podanie. Dzięki temu nie naruszysz zasady DRY (Nie powtarzaj się) i nie musisz robić zbyt wiele refaktoryzacji za każdym razem, gdy dodasz nową właściwość do swojego modelu domeny. Można również użyć frameworka, takiego jak Walidator NHibernate, aby raz zdefiniować całą walidację i użyć tej walidacji zarówno dla warstwy danych, jak i warstwy internetowej.

W przypadku większych aplikacji, które zawierają wiele oddzielnych usług (na przykład duże zestawy wewnętrznych aplikacji biznesowych), pożądane jest oddzielenie ORM od interfejsu usługi. Umożliwi to wprowadzanie zmian w modelach dostępu do danych bez zmiany interfejsu usługi (i na odwrót), co jest niezwykle cenne, gdy wiele innych usług zależy od stabilności interfejsu.

Jednak opisywana sytuacja (przy użyciu metod zmiany określonych właściwości) nie pasuje do żadnego z poniższych scenariuszy: ogólnie zły jest postępować zgodnie z opisanym przez siebie wzorcem, ponieważ powoduje on śledzenie ścieżek wykonania i refaktoryzację bardzo trudne (i może prowadzić do kodu spaghetti). Jedynym możliwym zastosowaniem, o którym myślę, jest to, że twoje modele danych są bardzo duże (blk 5k, itp.), A wysłanie ich przez warstwę usługi generuje duże ilości ruchu. (Uwaga: obiekty C# są dużo mniejsze niż 5k, jeśli serializowane są poprawnie!)

Zalecam przekazanie całego modelu dostępu do danych do warstwy internetowej.

Answer 3

przedwczesna optymalizacja jest źródłem wszelkiego zła

nawet w transakcje wysokiej częstotliwości, gdzie 50 nanosekund względu na to, co robisz, co jest słuszne, a pierwszy następnie zoptymalizować w razie potrzeby. Byłbyś zaskoczony, co mogą zrobić nowoczesne kompilatory/przepustowość sieci.

Aby odpowiedzieć na swoje pytanie bardziej bezpośrednio => przekazać te obiekty i nie myśleć o wydajności. Będziesz, jeśli będziesz musiał później, ale jest to bardzo mało prawdopodobne, że będzie to spowodowane przez przekazywanie obiektów w pobliżu.