Filozofie podejścia do wdrażania
podejście do wodospadu
Podejście kaskadowe do implementacji aplikacji wymaga, aby projektant skonsultował się z jednym lub kilkoma przedstawicielami organizacji użytkowników końcowych i spisał wszystkie specyfikacje aplikacji. Zazwyczaj specyfikacje są dostarczane w zestawie dokumentów funkcjonalnych lub przypadków użycia, napisanych w taki sposób, aby użytkownik końcowy mógł je łatwo przeczytać i zrozumieć.
Użytkownik końcowy podpisuje te dokumenty, a następnie dokumenty są zbierane przez zespół projektantów technicznych, który projektuje aplikację, tworząc różne artefakty, takie jak diagramy modeli klas, diagramy stanów, diagramy aktywności i modele danych. Celem tej fazy jest napisanie wszystkiego tak szczegółowo, aby programista nie miał problemu z utworzeniem niezbędnego kodu. Następuje formalne przekazanie projektu zespołowi deweloperskiemu i zespołowi testowemu. Po dostarczeniu produktu zespół programistów rozpoczyna kodowanie, a zespół testowy wykorzystuje projekt techniczny w połączeniu z przypadkami użycia do tworzenia przypadków testowych i scenariuszy testowych.
Po zakończeniu kodowania przez zespół programistów kod jest przekazywany zespołowi testowemu. Zespół testowy wykonuje zaprojektowane przez siebie testy w oparciu o wymagania i szczegółowy projekt. Wszelkie problemy zostaną rozwiązane przez zespół programistów. Po zakończeniu procesu testowania i naprawy aplikacja jest dostarczana użytkownikowi końcowemu do testów akceptacyjnych. Użytkownik końcowy przeprowadza ostateczną kontrolę, aby sprawdzić, czy aplikacja spełnia początkowe wymagania. Jeśli zostanie zatwierdzony, zatwierdza gotowy produkt i projekt jest zakończony. Po zakończeniu kodowania przez zespół programistów kod jest przekazywany zespołowi testowemu.
Zespół testowy wykonuje zaprojektowane przez siebie testy w oparciu o wymagania i szczegółowy projekt. Wszelkie problemy zostaną rozwiązane przez zespół programistów. Po zakończeniu procesu testowania i naprawy aplikacja jest dostarczana użytkownikowi końcowemu do testów akceptacyjnych. Użytkownik końcowy przeprowadza ostateczną kontrolę, aby sprawdzić, czy aplikacja spełnia wstępne wymagania. Jeśli zostanie zatwierdzony, zatwierdza gotowy produkt i projekt jest zakończony. Po zakończeniu kodowania przez zespół programistów kod jest przekazywany zespołowi testowemu. Zespół testowy wykonuje zaprojektowane przez siebie testy w oparciu o wymagania i szczegółowy projekt.
Wszelkie problemy zostaną rozwiązane przez zespół programistów. Po zakończeniu procesu testowania i naprawy aplikacja jest dostarczana użytkownikowi końcowemu do testów akceptacyjnych. Użytkownik końcowy przeprowadza ostateczną kontrolę, aby sprawdzić, czy aplikacja spełnia wstępne wymagania. Jeśli zostanie zatwierdzony, zatwierdza gotowy produkt i projekt jest zakończony.
Użytkownik końcowy przeprowadza ostateczną kontrolę, aby sprawdzić, czy aplikacja spełnia początkowe wymagania. Jeśli zostanie zatwierdzony, zatwierdza gotowy produkt i projekt jest zakończony. Użytkownik końcowy przeprowadza ostateczną kontrolę, aby sprawdzić, czy aplikacja spełnia początkowe wymagania. Jeśli zostanie zatwierdzony, zatwierdza gotowy produkt i projekt jest zakończony.
W przypadku podejścia kaskadowego projekt może mieć mniej lub więcej faz, ale kluczową cechą jest bardzo formalny początek i koniec każdej fazy, z bardzo formalnymi rezultatami.
Zaletą podejścia kaskadowego jest większa odpowiedzialność zespołu odpowiedzialnego za każdą fazę. Jest jasne, co muszą dostarczyć, kiedy muszą to dostarczyć i komu muszą to dostarczyć. Często zespół programistów nie będzie musiał wchodzić w interakcje z użytkownikiem. Może to być bardzo przydatne w przypadku outsourcingu rozwoju do innego kraju.
Główną wadą podejścia kaskadowego jest to, że w środowisku, w którym wszystko jest zorganizowane w bardzo formalny sposób, zmniejsza się elastyczność reagowania na zmiany. Nawet przeprowadzkę trzeba zorganizować. Wydaje się, że bardzo niewiele firm robi to skutecznie, co często prowadzi do znacznego wzrostu kosztów ogólnych. Aby zarządzać kosztami projektu, niektóre firmy opóźniają nawet wprowadzenie zmian w wymaganiach do momentu dostarczenia pierwszej aplikacji, w efekcie dostarczając aplikację, która nie spełnia wymagań użytkownika końcowego.
zwinny rozwój
Wiele długotrwałych projektów programistycznych przekroczyło budżet i nie dostarczyło produktu na czas. Założeniem filozofii zwinnego tworzenia oprogramowania jest minimalizowanie ryzyka poprzez tworzenie oprogramowania w krótkich przedziałach czasowych, zwanych iteracjami, które zwykle trwają od jednego do czterech tygodni. Każda iteracja jest jak własny miniaturowy projekt oprogramowania i obejmuje wszystkie zadania niezbędne do wydania przyrostu nowej funkcjonalności: planowanie, analiza wymagań, projektowanie, kodowanie, testowanie i dokumentacja. Podczas gdy iteracja może nie dodać wystarczającej funkcjonalności, aby zagwarantować wydanie produktu, zwinny projekt oprogramowania ma na celu umożliwienie wydania nowego oprogramowania na końcu każdej iteracji. Na koniec każdej iteracji zespół ponownie ocenia priorytety projektu.
Celem zwinnego tworzenia oprogramowania jest osiągnięcie zadowolenia klienta poprzez szybkie i ciągłe dostarczanie użytecznego oprogramowania; zawsze dążąc do zbudowania tego, czego potrzebuje klient; raczej z zadowoleniem niż przeciwstawiać się późnym zmianom w wymaganiach; regularnie dostosowywać się do zmieniających się okoliczności; bliskiej i codziennej współpracy przedsiębiorców z deweloperami, w której rozmowa twarzą w twarz jest najlepszą formą komunikacji.
Główną zaletą zwinnego tworzenia oprogramowania jest elastyczność w radzeniu sobie ze zmianami, zawsze dążąc do dostarczania zgodnie z potrzebami biznesowymi. Wadą jest oczywiście wzrost złożoności zarządzania zakresem, planowaniem i budżetowaniem. Innym powszechnym ryzykiem jest ograniczone zwracanie uwagi na dokumentację (techniczną).
Rozwój przyrostowy
Przyrostowe tworzenie oprogramowania to połączenie zwinnego i kaskadowego rozwoju. Aplikacja jest projektowana, wdrażana i testowana przyrostowo, tak aby każdy przyrost mógł być dostarczony użytkownikowi końcowemu. Projekt nie jest zakończony, dopóki nie zostanie ukończony ostatni przyrost. Ma na celu skrócenie kaskady poprzez zdefiniowanie pośrednich przyrostów i wykorzystanie niektórych zalet zwinnego programowania. W oparciu o informacje zwrotne otrzymane na temat poprzedniego przyrostu, można wprowadzić korekty podczas dostarczania kolejnego przyrostu. Kolejnym przyrostem może być zarówno nowy kod, jak i modyfikacje wcześniej dostarczonego kodu.
Zaletą jest to, że formalności pozostają na swoim miejscu, ale zarządzanie zmianą staje się łatwiejsze. Wielokrotne testowanie i wdrażanie aplikacji będzie kosztować więcej niż wykonanie tego tylko raz.
Kontrola przepływu programu
Wybór podejścia do sterowania przepływem programu jest zadaniem bardzo architektonicznym. Celem jest stworzenie planu aplikacji, w którym po rozpoczęciu dodawania funkcjonalności i kodu wszystko wydaje się mieć swoje własne miejsce. Jeśli kiedykolwiek recenzowałeś lub pisałeś kod wysokiej jakości, rozumiesz tę zasadę.
Kod Organizatora
Pierwszym krokiem w projektowaniu przepływu programu jest zorganizowanie kodu poprzez ustanowienie zestawu reguł, które pomogą stworzyć plan lub zarys aplikacji. Konserwacja, debugowanie i naprawianie błędów będzie łatwiejsze, ponieważ kod znajduje się w logicznej lokalizacji. Po wykonaniu podstaw możesz wybrać podejście do implementacji logiki aplikacji.
Wzorce projektowe powinny odgrywać ważną rolę w projektowaniu sterowania przepływem programu. Na przestrzeni lat napisano wiele kodu i zaprojektowano wiele rozwiązań dla powtarzających się problemów. Rozwiązania te są ułożone we wzorcach projektowych. Zastosowanie wzorca projektowego do typowego problemu projektowego oprogramowania pomoże Ci stworzyć rozwiązania, które będą łatwo rozpoznawalne i mogą być wdrażane przez Twoich rówieśników. Unikalne problemy nadal będą wymagały unikalnych rozwiązań, ale możesz użyć wzorców projektowych, aby pomóc Ci je rozwiązać.
Tworzenie projektu
warstwy
Pierwszym krokiem jest rozważenie warstw logicznych. Zauważ, że warstwy to nie to samo, co warstwy, często mylone lub nawet uważane za to samo.
warstwy kontra warstwy
Warstwy polegają na tworzeniu granic w kodzie. Górna warstwa może mieć odniesienia do kodu w warstwach poniżej, ale warstwa nigdy nie może mieć odniesienia do kodu w warstwie powyżej. Warstwy odnoszą się do fizycznego rozmieszczenia warstw na wielu komputerach. Na przykład w aplikacji trójwarstwowej interfejs użytkownika jest przeznaczony do uruchamiania na komputerze stacjonarnym, logika aplikacji jest zaprojektowana do uruchamiania na serwerze aplikacji, a baza danych działa na serwerze bazy danych. warstwa może składać się z kilku warstw.
Rysunek 8-1: Podstawowa organizacja trójwarstwowa
Warstwy odnoszą się do poziomów abstrakcji. Warstwy pokazane na rysunku 8-1 sprawdzają się w większości zastosowań. Poziomy te są również określane jako trzy główne warstwy i mogą mieć różne inne nazwy. Z reguły kod w warstwie prezentacji może wywoływać usługi w warstwie logiki aplikacji, ale warstwa logiki aplikacji nie może wywoływać metody w warstwie prezentacji. Warstwa prezentacji nigdy nie powinna bezpośrednio wywoływać warstwy dostępu do danych, ponieważ spowodowałoby to pominięcie obowiązków realizowanych przez warstwę logiki aplikacji. Warstwa dostępu do danych nigdy nie powinna wywoływać warstwy logiki aplikacji.
Warstwy to tylko abstrakcja i prawdopodobnie najłatwiejszym sposobem ich implementacji jest utworzenie folderów w projekcie i dodanie kodu do odpowiedniego folderu. Bardziej użytecznym podejściem byłoby umieszczenie każdej warstwy w osobnym projekcie, tworząc w ten sposób osobne zespoły. Zaletą umieszczenia logiki aplikacji w zestawie biblioteki jest możliwość tworzenia testów jednostkowych przy użyciu programu Microsoft Visual Studio lub NUnit w celu przetestowania logiki. Zapewnia również elastyczność w wyborze miejsca wdrożenia każdej warstwy.
Warstwy fizyczne
W aplikacji korporacyjnej można oczekiwać wielu klientów dla tej samej logiki. W rzeczywistości tym, co sprawia, że aplikacja jest aplikacją korporacyjną, jest to, że zostanie wdrożona w trzech warstwach: klient, serwer aplikacji i serwer bazy danych. Aplikacja Microsoft Office Access stworzona przez dział sprzedaży Twojej firmy, choć bardzo ważna dla działu sprzedaży, nie jest aplikacją korporacyjną.
Należy zauważyć, że logika aplikacji i warstwy dostępu do danych są często wdrażane razem na serwerze aplikacji. Częścią projektowania projektu jest wybór, czy uzyskać dostęp do serwera aplikacji za pomocą zdalnych usług .NET czy Web Services. Niezależnie od tego, co wybierzesz, dodasz trochę kodu, aby łatwo uzyskać dostęp do usług zdalnych w warstwie prezentacji. Jeśli korzystasz z usług sieci Web w celu uzyskania dostępu do usług na serwerze aplikacji, Visual Studio .NET wykona pracę za Ciebie i wygeneruje kod proxy, automatycznie dostarczając implementację wzorca zdalnego proxy.
Dodawanie wzorów do warstw
Trzy podstawowe warstwy zapewniają ogólny przegląd. Dodajmy kilka wzorców strukturalnych, aby stworzyć solidną architekturę korporacyjną. Wynik pokazano na rysunku 8-2.
Skoncentruj się na warstwie logiki aplikacji. Rysunek 8-2 pokazuje, że dostęp do logiki aplikacji odbywa się za pomocą wzorca fasady. Fasada to obiekt, który zapewnia uproszczony interfejs dla większej części kodu, takiej jak biblioteka klas. Fasada może zmniejszyć zależność kodu zewnętrznego od wewnętrznego działania biblioteki, ponieważ większość kodu wykorzystuje fasadę, co pozwala na większą elastyczność w rozwoju systemu. Aby to zrobić, fasada zapewni gruboziarnisty interfejs dla kolekcji drobnoziarnistych obiektów.
przepływ decyzji
Sterowanie przepływem programu, znane również jako przepływ decyzji, dotyczy sposobu projektowania usług w warstwie logiki aplikacji lub, jak widzieliśmy w poprzednim akapicie, sposobu projektowania metod w fasadzie.
Istnieją dwa podejścia do organizowania usług:
- zorientowany na działanie
- kierowane przez państwo
Podejście zorientowane na działanie
Organizując usługi na podstawie działań użytkownika, wdrażasz logikę aplikacji, oferując usługi, z których każda obsługuje określone żądanie z warstwy prezentacji. Jest to również znane jako wzorzec skryptu transakcji. To podejście jest popularne, ponieważ jest proste i wygląda bardzo naturalnie. Przykładami metod zgodnych z tym podejściem są BookStoreService.AddNewOrder(Order order) i BookStoreService.CancelOrder(int orderId).
Logika potrzebna do wykonania akcji jest implementowana bardzo sekwencyjnie w ramach metody, dzięki czemu kod jest bardzo czytelny, ale także trudniejszy do ponownego użycia. Korzystanie z dodatkowych wzorców projektowych, takich jak wzorzec modułu tabeli, może pomóc w zwiększeniu możliwości ponownego użycia.
Podejście sterowane przez państwo
Możliwe jest również zaimplementowanie przepływu decyzji aplikacji w sposób znacznie bardziej zorientowany na stan. Usługi oferowane przez serwer aplikacji mają bardziej ogólny charakter, na przykład BookStoreService.SaveOrder(Order order). Ta metoda zbada status zamówienia i zdecyduje, czy dodać nowe zamówienie, czy anulować istniejące.
Projekty struktury danych
Podczas projektowania struktur danych musisz dokonać kilku wyborów. Pierwszym wyborem jest mechanizm przechowywania danych, drugim przeznaczeniem danych, a trzecim wymagania dotyczące wersji. Projekty struktur danych można rozpatrywać na trzy sposoby:
- Usługi oferują dane; data jest odzwierciedleniem relacyjnej bazy danych.
- Dane muszą być mapowane na obiekty, a usługi zapewniają dostęp do obiektów.
- Dane oferowane przez usługi muszą być oparte na schemacie.
Wybór jednego z trzech jako podstawy struktury przepływu danych powinien zostać dokonany na wczesnym etapie procesu projektowania. Wiele firm ma wytyczne firmowe, które nakazują jedną z trzech opcji we wszystkich projektach, ale tam, gdzie to możliwe, należy ponownie ocenić opcje dla każdego projektu, wybierając optymalne podejście do danego projektu.
Wybór silnika przechowywania danych
Projektując swoją aplikację, z pewnością będziesz musiał zaprojektować jakiś magazyn danych. Dostępne są następujące sklepy i formy przechowywania danych:
- Nagrywać
- plik app.config
- pliki XML
- zwykłe pliki tekstowe
- Baza danych
- kolejkowanie wiadomości
Każdy sklep ma swoje unikalne cechy i może być dostosowany do konkretnych wymagań.
Projektowanie przepływu danych
Przepływ danych przy użyciu ADO.NET
Implementując usługi data-centric w warstwie logiki aplikacji, zaprojektujesz przepływ danych z wykorzystaniem ADO.NET. Biblioteka klas .NET Framework zapewnia rozbudowany interfejs programowania aplikacji (API) do manipulowania danymi w kodzie zarządzanym. Określany jako ADO.NET, API można znaleźć w przestrzeni nazw System.Data. Całkowite rozdzielenie nośników danych i magazynów danych to ważna cecha konstrukcyjna ADO.NET. Klasy takie jak DataSet, DataTable i DataRow są przeznaczone do przechowywania danych, ale nie przechowują informacji o pochodzeniu danych. Są one uważane za niezależne od źródła danych. Oddzielny zestaw klas, takich jak SqlConnection, SqlDataAdapter i SqlCommand, zajmuje się łączeniem ze źródłem danych, pobieraniem danych i wypełnianiem DataSet, DataTable i DataRow. Klasy te znajdują się w podrzędnych przestrzeniach nazw, takich jak System.Data.Sql, System.Data.OleDB, System.Data.Oracle i tak dalej. W zależności od źródła danych, z którym chcesz się połączyć, możesz użyć klas w odpowiedniej przestrzeni nazw, a w zależności od zakresu używanego produktu przekonasz się, że te klasy oferują mniej lub więcej funkcji.
Ponieważ DataSet nie jest połączony ze źródłem danych, może być z powodzeniem używany do zarządzania przepływem danych w aplikacji. Rysunek 8-5 przedstawia przepływ danych podczas wykonywania tej czynności.
Przyjrzyjmy się temu projektowi i wyobraźmy sobie, że ktoś zalogował się do Twojej księgarni i zamówił trzy książki. Warstwa prezentacji zarządzała stanem koszyka. Klient jest gotowy do złożenia zamówienia i podał wszystkie niezbędne dane. Decyduje się wysłać zamówienie. Strona internetowa przekształca wszystkie dane w DataSet zawierający dwie tabele DataTables, jedną dla zamówienia i jedną dla zamówienia; wstawia DataRow dla zamówienia; i wstawia trzy DataRows dla wierszy zamówienia. Następnie strona internetowa ponownie wyświetla te dane użytkownikowi, wiążąc kontrolki danych z zestawem danych i pytając Czy na pewno? Użytkownik potwierdza żądanie i jest ono przesyłane do warstwy logicznej aplikacji. Warstwa logiki aplikacji sprawdza DataSet, aby zobaczyć, czy wszystkie wymagane pola mają wartość, i wykonuje sprawdzenie, czy użytkownik ma więcej niż 1000 US$. 00 na zaległe rachunki. Jeśli wszystko pójdzie dobrze, DataSet jest przekazywany do warstwy dostępu do danych, która łączy się z bazą danych i generuje instrukcje wstawiania z informacji DataSet.
Korzystanie z DataSet w ten sposób jest szybkim i wydajnym sposobem na zbudowanie aplikacji i wykorzystanie możliwości Framework Class Library oraz możliwości ASP.NET do powiązania danych z różnymi formantami, takimi jak GridView względem DataSet. Zamiast używać prostych obiektów DataSet, możesz użyć obiektów Typed DataSet i poprawić środowisko kodowania, implementując kod w warstwie prezentacji, a także w warstwie logiki aplikacji. Zaletą tego podejścia jest również wada tego podejścia. Niewielkie zmiany w modelu danych niekoniecznie prowadzą do konieczności zmiany sygnatur wielu metod. Więc jeśli chodzi o konserwację, działa to naprawdę dobrze. Jeśli pamiętasz, że warstwa prezentacji niekoniecznie jest interfejsem użytkownika, może to być również usługa internetowa. A jeśli zmodyfikujesz definicję DataSet, być może dlatego, że zmieniasz nazwę pola w bazie danych, modyfikujesz umowę, którą subskrybuje usługa internetowa. Jak możesz sobie wyobrazić, może to prowadzić do poważnych problemów. Ten scenariusz działa dobrze, jeśli warstwa prezentacji jest tylko interfejsem użytkownika, ale w przypadku interfejsów do zewnętrznych systemów lub komponentów będziesz chciał ukryć wewnętrzne działanie aplikacji i przekształcić dane w coś innego niż bezpośredni klon twojego modelu danych i będziesz chciał utworzyć obiekty przesyłania danych (DTO).
Przepływ danych z wykorzystaniem mapowania obiektowo-relacyjnego
Przepływ danych przy użyciu ADO.NET to bardzo skoncentrowane na danych podejście do zarządzania przepływem danych. Dane i logika są dyskretne. Drugi koniec spektrum to podejście bardziej obiektowe. Tutaj tworzone są klasy w celu grupowania danych i zachowań. Celem jest zdefiniowanie klas, które naśladują dane i zachowanie znalezione w domenie biznesowej, dla której utworzono aplikację. Wynik jest często określany jako obiekt biznesowy. Zbiór obiektów biznesowych składających się na aplikację jest nazywany modelem domeny. Niektórzy programiści twierdzą, że bogaty model domeny jest lepszy do projektowania bardziej złożonej logiki. Trudno jest udowodnić lub obalić takie stwierdzenie. Po prostu wiedz, że masz wybór i to od ciebie zależy, czy go dokonasz.
Na rysunku 8.6 przedstawiono przepływ danych podobny do tego na rysunku 8.5, z tą różnicą, że teraz dodano warstwę mapowania relacji obiektowych i zastąpiono obiekty DataSet różnymi nośnikami danych.
Teraz wykonaj to samo krok po kroku, co poprzednio; wyobraź sobie, że ktoś połączył się z Twoją księgarnią i zamówił trzy książki. Warstwa prezentacji zarządzała stanem koszyka. Klient jest gotowy do złożenia zamówienia i podał wszystkie niezbędne dane. Decyduje się wysłać zamówienie. Strona internetowa przekształca wszystkie dane w DTO, przechowując dane dla jednego zamówienia iz trzema wierszami zamówienia, tworząc obiekty w razie potrzeby. Strona sieci Web ponownie wyświetla te dane użytkownikowi, kontroluje powiązania danych z DTO przy użyciu elementu ObjectDataSource w ASP.NET 2.0 i pyta Czy na pewno? Użytkownik potwierdza wybór, a DTO jest przesyłane do warstwy logicznej aplikacji. Warstwa logiki aplikacji przekształca DTO w obiekt biznesowy typu Order z właściwością zawierającą trzy obiekty OrderLine. Metoda Order. Funkcja Validate() jest wywoływana w celu zatwierdzenia zamówienia i zweryfikowania, czy wszystkie wymagane pola mają wartość, oraz sprawdzane jest, czy użytkownik ma więcej niż 1000,00 R$ w oczekujących odcinkach. W tym celu zamówienie wywoła funkcję Order.Customer.GetOutstandingBills(). Jeśli wszystko jest w porządku, wywoływana jest metoda Order.Save(). Żądanie przejdzie przez warstwę mapowania relacji obiektowych, gdzie żądanie i wiersze żądania są mapowane na DataTable w DataSet, a DataSet jest przekazywany do warstwy dostępu do danych, która łączy się z bazą danych i generuje instrukcje wstawiania z informacje w zbiorze danych. Istnieje oczywiście wiele sposobów mapowania obiektowo-relacyjnego, ale nie wszystkie obejmują transformację do zbioru danych. Niektórzy utworzą instrukcję wstawiania bezpośrednio, ale nadal będą używać warstwy dostępu do danych do wykonania tej instrukcji.
Jak widać, zachodzą pewne przemiany. Użycie DTO jest konieczne, ponieważ obiekt biznesowy implementuje zachowanie, które może ulec zmianie. Aby zminimalizować wpływ tych zmian na warstwę prezentacji, należy przekształcić dane z obiektu biznesowego w obiekt przesyłania danych. W języku Java obiekt przesyłania danych jest często nazywany obiektem wartości.
Dużą zaletą pracy z obiektami biznesowymi jest to, że naprawdę pomaga to w organizacji kodu. Jeśli spojrzysz wstecz na kawałek złożonej logiki, zwykle jest to bardzo czytelne, ponieważ jest tam bardzo mało kodu instalacyjnego. Wadą jest to, że większość magazynów danych jest nadal relacyjna, a odwzorowywanie obiektów biznesowych na dane relacyjne może być dość skomplikowane.
usługi oparte na schematach
Właśnie widziałeś dwa przeciwieństwa, jeśli chodzi o zarządzanie przepływem danych. Możliwych jest wiele wariantów. Powszechny jest wariant, w którym zbiór danych jest używany jako podstawowy nośnik danych interfejsu użytkownika do przechowywania danych, ale oddzielne schematy (DTO) są wykorzystywane do usług internetowych wywoływanych z innych systemów. Warstwa aplikacji przekształca dane relacyjne w predefiniowany schemat. Główną zaletą tego rozwiązania jest to, że żadna aplikacja odwołująca się do usługi nie jest zależna od jakiejkolwiek wewnętrznej implementacji komponentu. Pozwala to na większą elastyczność w wersjonowaniu, kompatybilność wsteczną interfejsów oraz możliwość zmiany implementacji komponentu bez zmiany interfejsu usługi.
Oczywiście można używać obiektów biznesowych w aplikacji internetowej i ominąć transformację DTO, ale zazwyczaj działa to dobrze tylko wtedy, gdy logika aplikacji jest zaimplementowana razem z aplikacją internetową. Pamiętaj, że aby wywołać Order.Save() będziesz potrzebować połączenia z bazą danych. To, czy jest to pożądane, zależy od Ciebie i prawdopodobnie od Twojego dyrektora ds. bezpieczeństwa.