Projektowanie, Programowanie, Codzienność – BeniaminZaborski.com

13 Maj 2009

DO or not DO?

Filed under: Codzienne dylematy modelarza — Tags: , , , , — Beniamin Zaborski @ 07:06

DO or not DO? DO jak Data Object, zwane także DTO – Data Transfer Object, VO – Value Object czy nawet Presentation Entity. Używać czy nie używać?
Oczywiście nie spodziewajcie się jednoznacznej odpowiedzi, a jeśli już taka padnie to pewnie będzie dość subiektywna. Problem ten przewija się na wielu forach i stosowanie obiektów DTO ma tyle samo przeciwników co zwolenników. Dużo zależy jednak od aplikacji jaką piszemy, od jej typu, rozmiaru, itp. Ja jednak obecnie zaliczam się do grupy zwolenników stosowania obiektów DTO (choć może mnie ktoś przekona i zmienię zdanie). Czemu? To postaram się właśnie tutaj przedstawić. Zanim jednak zacznę należy się krótkie wprowadzenie teoretyczne.
Czasy gdzie dominującym modelem architektonicznym w aplikacjach biznesowych był klient-serwer bezpowrotnie (mam nadzieję) minęły. Dziś przystępując do projektu z góry zakładamy model n-warstwowy (szczególnie 3-warstwowy). Oznacza to, że w naszej aplikacji będzie można wyróżnić co najmniej następujące warstwy logiczne:
– warstwa dostępu do danych
– warstwa logiki biznesowej
– warstwa prezentacji.
Jest to model bardzo ogólny i odnosi się do wszystkich typów aplikacji czy to web-owych czy desktopowych. W kontekście poruszanego tematu nas najbardziej będzie interesować styk warstwy logiki biznesowej i warstwy prezentacji.
Nasuwa się pytanie: czy do warstwy prezentacji przesyłać bezpośrednio encje biznesowe? Ja jednak postawię to pytanie inaczej: dlaczego nie przesyłać do warstwy prezentacji encji biznesowych?
Jak już wspomniałem wcześniej jestem zwolennikiem stosowania obiektów DTO. Zdaję sobie sprawę, że wymaga to dodatkowej pracy (co często wytykają przeciwnicy), ale to procentuje później.
Warto zerknąć tutaj i zobaczyć jak Martin Fowler przedstawia Data Transfer Object.

Oto co przemawia za tym rozwiązaniem:

1) Luźnie powiązania.

Podstawową zaletą takiego rozwiązania jest wprowadzenie kolejnego luźniejszego powiązania pomiędzy warstwą logiki biznesowej, a prezentacji. Ma to szczególne znaczenie, kiedy nagle okaże się, iż trzeba dokonać pewnych zmian w warstwie prezentacji. W ten sposób często unikamy modyfikacji w warstwie logiki biznesowej, co wydaje się być dobre.

Przeciwnicy powiedzą: W większości typowych przypadków i tak dokonanie zmian w warstwie logiki biznesowej będzie niezbędne.

2) Różne wymagania.

Encja reprezentująca jakiś fragment naszego biznesu z jednej strony musi komunikować się z klientem (warstwa prezentacji), a z drugiej z repozytorium w którym jest przechowywana (warstwa dostępu do danych). Oba te wymagania nakładają na encje pewne zadania. Patrząc od strony warstwy dostępu do danych to powinno być możliwe wykonanie operacji CRUD na encji. Czy to poprzez procedury składowane, czy mechanizm O/R Mapping-u. Z drugiej strony encja powinna współpracować z warstwą prezentacji, tj. bindować się z kontrolkami, obsługiwać mechanizmy powiadamiania o niespełnionych regułach walidacyjnych itp. To znowu nakłada na każdą encje zupełnie inne zadania. Stąd warto rozdzielić te dwa jakże odmiene od siebie grupy zadań, powierzając komunikację z warstwą prezentacji właśnie specjalnie do tego wydzielonym obiektom DTO.

Przeciwnicy powiedzą: Zbyt duży nakład pracy, a korzyści nie tak widoczne jak by się można było tego spodziewać.

3) Większa wydajność.

W czasach systemów rozproszonych często warstwy aplikacji znajdują się na różnych maszynach stąd komunikują się poprzez sieć. Komunikacja ta może się odbywać z wykorzystaniem różnych mechanizmów jak WebService (SOAP), .NET Remoting, COM+, itp. Często do pojedynczych widoków w warstwie prezentacji przesyłamy tylko część danych z encji. Nie zawsze encje pokrywają się 1 do 1 z widokami. Zamiast przesyłać poprzez sieć duże obiekty encji biznesowych warto przepakować do obiektów DTO tylko te dane, które faktycznie będą nam potrzebne w widoku.

Przeciwnicy powiedzą: W dzisiejszych czasach wydajność systemów to nie problem, zresztą kto na to zwraca uwagę.

Jak napisałem na początku odpowiedzi jednoznacznej nie ma. Bez dwóch zdań koszty pracy związane ze stosowaniem obiektów DTO są wyższe, no  przynajmniej na początku. Warto rozważyć, przed przystąpieniem do nowego projektu, stosowanie obiektów DTO, co nie oznacza, że w każdym przypadku będzie to trafione rozwiązanie. A więc pytanie „DO or not DO” pozostaje otwarte …

2 komentarzy »

  1. Nie napisałeś co w zamian. Natomiast co do DTO to ja także je używam :)

    Komentarz - autor: dario-g — 22 Maj 2009 @ 21:40

    • Napisałem, że w zamian … przesyłanie wprost encji biznesowych do warstwy prezentacji.

      Komentarz - autor: Beniamin Zaborski — 22 Maj 2009 @ 21:46


RSS feed for comments on this post. TrackBack URI

Skomentuj

Wprowadź swoje dane lub kliknij jedną z tych ikon, aby się zalogować:

Logo WordPress.com

Komentujesz korzystając z konta WordPress.com. Log Out / Zmień )

Zdjęcie z Twittera

Komentujesz korzystając z konta Twitter. Log Out / Zmień )

Facebook photo

Komentujesz korzystając z konta Facebook. Log Out / Zmień )

Google+ photo

Komentujesz korzystając z konta Google+. Log Out / Zmień )

Connecting to %s

Blog na WordPress.com.

%d bloggers like this: