Megvalósítási megközelítési filozófiák
vízesés megközelítés
Az alkalmazás megvalósításának vízeséses megközelítése megköveteli, hogy a tervező konzultáljon a végfelhasználói szervezet egy vagy több képviselőjével, és írja le az alkalmazás összes specifikációját. A specifikációk jellemzően funkcionális dokumentumok vagy használati esetek halmazaként jelennek meg, oly módon írva, hogy a végfelhasználó könnyen elolvassa és megértse a dokumentumokat.
A végfelhasználó aláírja ezeket a dokumentumokat, majd a dokumentumokat az alkalmazást tervező műszaki tervezőcsapat gyűjti össze, és különféle műtermékeket hoz létre, például osztálymodell diagramokat, állapotdiagramokat, tevékenységdiagramokat és adatmodelleket. Ennek a fázisnak az a célja, hogy mindent olyan részletesen írjunk le, hogy a fejlesztőnek ne okozzon gondot a szükséges kód elkészítése. A tervezést hivatalosan átadják a fejlesztőcsapatnak és a tesztcsoportnak. A szállítást követően a fejlesztőcsapat megkezdi a kódolást, a tesztcsapat pedig a műszaki tervezést a használati esetekkel kombinálva teszteseteket és tesztforgatókönyveket készít.
Miután a fejlesztőcsapat befejezte a kódolást, a kódot átadják a tesztcsapatnak. A tesztcsoport elvégzi az általa tervezett teszteket a követelmények és a részletes tervezés alapján. Az esetleges problémákat a fejlesztőcsapat orvosolja. A tesztelési és javítási folyamat befejezése után az alkalmazást átadják a végfelhasználónak átvételi tesztelés céljából. A végfelhasználó elvégzi az utolsó ellenőrzést, hogy megbizonyosodjon arról, hogy az alkalmazás megfelel-e a kezdeti követelményeknek. Jóváhagyás esetén jóváhagyja a kész terméket, és a projekt befejeződik. Miután a fejlesztőcsapat befejezte a kódolást, a kódot átadják a tesztcsapatnak.
A tesztcsoport elvégzi az általa tervezett teszteket a követelmények és a részletes tervezés alapján. Az esetleges problémákat a fejlesztőcsapat orvosolja. A tesztelési és javítási folyamat befejezése után az alkalmazást átadják a végfelhasználónak átvételi tesztelés céljából. A végfelhasználó elvégzi az utolsó ellenőrzést, hogy megbizonyosodjon arról, hogy az alkalmazás megfelel-e a kezdeti követelményeknek. Jóváhagyás esetén jóváhagyja a kész terméket, és a projekt befejeződik. Miután a fejlesztőcsapat befejezte a kódolást, a kódot átadják a tesztcsapatnak. A tesztcsoport elvégzi az általa tervezett teszteket a követelmények és a részletes tervezés alapján.
Az esetleges problémákat a fejlesztőcsapat orvosolja. A tesztelési és javítási folyamat befejezése után az alkalmazást átadják a végfelhasználónak átvételi tesztelés céljából. A végfelhasználó elvégzi az utolsó ellenőrzést, hogy megbizonyosodjon arról, hogy az alkalmazás megfelel-e a kezdeti követelményeknek. Jóváhagyás esetén jóváhagyja a kész terméket, és a projekt befejeződik.
A végfelhasználó elvégzi az utolsó ellenőrzést, hogy megbizonyosodjon arról, hogy az alkalmazás megfelel-e a kezdeti követelményeknek. Jóváhagyás esetén jóváhagyja a kész terméket, és a projekt befejeződik. A végfelhasználó elvégzi az utolsó ellenőrzést, hogy megbizonyosodjon arról, hogy az alkalmazás megfelel-e a kezdeti követelményeknek. Jóváhagyás esetén jóváhagyja a kész terméket, és a projekt befejeződik.
Egy projektnek több vagy kevesebb fázisa is lehet, ha a vízesés megközelítést alkalmazzuk, de a legfontosabb jellemző az egyes fázisok nagyon formális kezdete és vége, nagyon formális teljesítménnyel.
A vízesés megközelítés előnye, hogy az egyes fázisokért felelős csapat felelőssége nagyobb. Világos, hogy mit kell szállítaniuk, mikor kell szállítaniuk, és kinek kell szállítaniuk. A fejlesztőcsapatnak gyakran nem kell kapcsolatba lépnie a felhasználóval. Ez nagyon hasznos lehet, ha a fejlesztést egy másik országba bízza ki.
A vízesés megközelítés fő hátránya, hogy egy olyan környezetben, ahol minden nagyon formálisan van megszervezve, csökken a változásokra való reagálás rugalmassága. Még a költözést is meg kell szervezni. Úgy tűnik, nagyon kevés vállalat teszi ezt hatékonyan, ami gyakran jelentős rezsiköltség-növekedést eredményez. Egy projekt költségeinek kezelése érdekében egyes vállalatok a követelmények módosítását is elhalasztják az alkalmazás kezdeti kézbesítéséig, és gyakorlatilag olyan alkalmazást szállítanak, amely nem felel meg a végfelhasználó igényeinek.
agilis fejlesztés
Sok régóta futó szoftverfejlesztési projekt túllépte a költségvetést, és nem szállították le időben a terméket. Az agilis szoftverfejlesztési filozófia előfeltétele a kockázat minimalizálása azáltal, hogy a szoftvert rövid időkeretekben, úgynevezett iterációkban fejlesztik, amelyek jellemzően egy-négy hétig tartanak. Minden iteráció olyan, mint a saját miniatűr szoftverprojektje, és magában foglalja az összes olyan feladatot, amely az új funkciók felszabadításához szükséges: tervezés, követelményelemzés, tervezés, kódolás, tesztelés és dokumentáció. Bár előfordulhat, hogy egy iteráció nem ad elegendő funkcionalitást ahhoz, hogy garantálja a termék kiadását, egy agilis szoftverprojekt célja, hogy minden iteráció végén új szoftvert tudjon kiadni. Minden iteráció végén a csapat újraértékeli a projekt prioritásait.
Az agilis szoftverfejlesztés célja a vevői elégedettség elérése hasznos szoftverek gyors és folyamatos szállításával; mindig arra törekszik, hogy megépítse azt, amire az ügyfélnek szüksége van; inkább üdvözöljék, semmint ellenezzék a követelmények késői módosításait; rendszeresen alkalmazkodni a változó körülményekhez; a vállalkozók és a fejlesztők közötti szoros és napi együttműködés, amelyben a személyes beszélgetés a legjobb kommunikációs forma.
Az agilis szoftverfejlesztés fő előnye a változások kezelésének rugalmassága, mindig az üzleti igényeknek megfelelő teljesítésre törekedve. Hátránya természetesen a hatókör kezelésének, a tervezésnek és a költségvetés-készítés bonyolultságának növekedése. Egy másik gyakori kockázat a (műszaki) dokumentációra való korlátozott figyelem.
Inkrementális fejlesztés
A növekményes szoftverfejlesztés az agilis és a vízesés fejlesztés keveréke. Az alkalmazásokat fokozatosan tervezik, implementálják és tesztelik, hogy minden egyes lépést el lehessen juttatni a végfelhasználóhoz. A projekt addig nem fejeződik be, amíg az utolsó lépés el nem készül. Célja a kaszkád lerövidítése köztes lépések meghatározásával és az agilis fejlesztés egyes előnyeinek felhasználásával. Az előző növekményről kapott visszajelzések alapján a következő növekmény kézbesítésekor módosíthatók. A következő lépés új kódból, valamint a korábban megadott kód módosításaiból állhat.
Előnye, hogy a formalitások érvényben maradnak, de a változáskezelés egyszerűbbé válik. Egy alkalmazás többszöri tesztelésének és üzembe helyezésének költsége magasabb lesz, mintha csak egyszer végezné el.
Program Flow Control
A programfolyamat-vezérlés megközelítésének kiválasztása nagyon architektonikus feladat. A cél az, hogy elkészítse az alkalmazás tervrajzát, ahol a funkciók és a kód hozzáadása után mindennek megvan a maga helye. Ha valaha is áttekintett vagy írt jó minőségű kódot, akkor megérti ezt az elvet.
Szervező kód
A programfolyamat tervezésének első lépése a kód rendszerezése egy olyan szabálykészlet létrehozásával, amely segít az alkalmazás tervrajzának vagy vázlatának elkészítésében. A karbantartás, a hibakeresés és a hibajavítás könnyebb lesz, mert a kód logikus helyen található. Miután elvégezte az alapmunkát, kiválaszthat egy megközelítést az alkalmazás logikájának megvalósításához.
A tervezési mintáknak fontos szerepet kell játszaniuk a programfolyamat-vezérlés tervezésében. Az évek során rengeteg kódot írtak, és számos megoldást terveztek az ismétlődő problémákra. Ezek a megoldások tervezési mintákban vannak lefektetve. A tervezési minta alkalmazása egy gyakori szoftvertervezési problémára segít olyan megoldások létrehozásában, amelyek könnyen felismerhetők, és társai is megvalósíthatják. Az egyedi problémák továbbra is egyedi megoldásokat igényelnek, de tervezési mintákat használhat a megoldásukhoz.
A Projekt létrehozása
rétegek
Az első lépés a logikai rétegek figyelembevétele. Vegye figyelembe, hogy a rétegek nem ugyanazok, mint a rétegek, gyakran összekeverik, vagy akár azonosnak is tekintik.
rétegek versus rétegek
A rétegek lényege, hogy határokat hozzon létre a kódban. A felső réteg tartalmazhat hivatkozásokat az alatta lévő rétegekben lévő kódra, de a réteg soha nem hivatkozhat a fenti rétegben lévő kódra. A szintek a szintek fizikai eloszlására utalnak több számítógép között. Például egy háromszintű alkalmazásban a felhasználói felületet asztali számítógépen való futtatásra tervezték, az alkalmazáslogikát alkalmazásszerveren való futtatásra, az adatbázis pedig egy adatbázis-kiszolgálón fut. réteg több rétegből is állhat.
8-1. ábra: Alapvető háromszintű szervezet
A rétegek az absztrakció szintjeit jelentik. A 8-1. ábrán látható rétegek a legtöbb alkalmazásra igazak. Ezeket a szinteket három fő rétegnek is nevezik, és számos más elnevezésük is lehet. Általános szabály, hogy a megjelenítési rétegben lévő kód meghívhatja az alkalmazáslogikai rétegben lévő szolgáltatásokat, de az alkalmazáslogikai réteg nem hívhatja meg a megjelenítési réteg metódusát. A megjelenítési réteg soha nem hívhatja meg közvetlenül az adathozzáférési réteget, mivel ez megkerülné az alkalmazáslogikai réteg által megvalósított felelősségeket. Az adathozzáférési réteg soha nem hívhatja meg az alkalmazáslogikai réteget.
A rétegek csak egy absztrakció, és valószínűleg a rétegek megvalósításának legegyszerűbb módja, ha mappákat hoz létre a projektben, és kódot ad hozzá a megfelelő mappához. Hasznosabb megközelítés lenne, ha minden réteget külön projektben helyeznénk el, így külön összeállításokat hoznánk létre. Az alkalmazáslogika könyvtár-összeállításba helyezésének előnye, hogy lehetővé teszi egységtesztek létrehozását a Microsoft Visual Studio vagy a NUnit segítségével a logika tesztelésére. Rugalmasságot biztosít az egyes rétegek telepítési helyének megválasztásában is.
Fizikai rétegek
Vállalati alkalmazásokban ugyanazon logikához több ügyfélre számíthat. Valójában az tesz egy alkalmazást vállalati alkalmazássá, hogy három rétegben kerül telepítésre: ügyfél, alkalmazáskiszolgáló és adatbázis-kiszolgáló. A vállalata értékesítési osztálya által létrehozott Microsoft Office Access alkalmazás, bár nagyon fontos az értékesítési osztály számára, nem vállalati alkalmazás.
Vegye figyelembe, hogy az alkalmazáslogikai és adatelérési rétegek gyakran együtt kerülnek telepítésre az alkalmazáskiszolgálón. A projekt tervezésének része annak kiválasztása, hogy az alkalmazáskiszolgálót távoli .NET vagy webszolgáltatások használatával kívánja-e elérni. Bármelyiket is választja, hozzá kell adni egy kódot, amellyel könnyedén elérheti a távoli szolgáltatásokat a bemutató rétegben. Ha webszolgáltatásokat használ az alkalmazáskiszolgálón lévő szolgáltatások eléréséhez, a Visual Studio .NET elvégzi a munkát Ön helyett, és létrehozza a proxykódot, automatikusan biztosítva a távoli proxy minta megvalósítását.
Minták hozzáadása a rétegekhez
A három alapréteg magas szintű áttekintést nyújt. Adjunk hozzá néhány szerkezeti mintát egy robusztus vállalati architektúra létrehozásához. Az eredmény a 8-2. ábrán látható.
Koncentráljon az alkalmazáslogikai rétegre. A 8-2. ábra azt mutatja, hogy az alkalmazáslogikához való hozzáférés a homlokzati mintát használja. A homlokzat egy olyan objektum, amely egyszerűsített felületet biztosít egy nagyobb kódtömeghez, például egy osztálykönyvtárhoz. A homlokzat csökkentheti a külső kódfüggéseket a könyvtár belső működésétől, mivel a legtöbb kód a homlokzatot használja, így nagyobb rugalmasságot tesz lehetővé a rendszerfejlesztésben. Ennek érdekében a homlokzat durva szemcsés felületet biztosít a finomszemcsés tárgyak gyűjteményéhez.
döntési folyamat
A programfolyamat-vezérlés, más néven döntési folyamat, arra vonatkozik, hogyan tervezi meg a szolgáltatásokat az alkalmazás logikai rétegében, vagy ahogy az előző bekezdésben látta, hogyan tervezi meg a módszereket a homlokzatán.
A szolgáltatások megszervezésének két módja van:
- cselekvésközpontú
- állam vezérelte
Akcióorientált megközelítés
A szolgáltatások felhasználói műveleteken alapuló szervezésével az alkalmazáslogikát olyan szolgáltatások kínálásával valósítja meg, amelyek mindegyike egy adott kérést kezel a megjelenítési rétegtől. Ezt tranzakciós szkriptmintának is nevezik. Ez a megközelítés népszerű, mert egyszerű és nagyon természetesnek tűnik. Az ezt a megközelítést követő metódusok például a BookStoreService.AddNewOrder(Rendelési sorrend) és a BookStoreService.CancelOrder(int orderId).
A művelet végrehajtásához szükséges logika nagyon szekvenciálisan valósul meg a metóduson belül, így a kód nagyon olvashatóvá válik, de egyben nehezebb is újrafelhasználni. További tervezési minták, például az asztali modulminta használata növelheti az újrafelhasználhatóságot.
Államvezérelt megközelítés
Lehetőség van az alkalmazás döntési folyamatának sokkal állapotorientáltabb megvalósítására is. Az alkalmazásszerver által kínált szolgáltatások általánosabb jellegűek, például BookStoreService.SaveOrder(Rendelési rendelés). Ez a módszer megvizsgálja a rendelés állapotát, és eldönti, hogy új rendelést ad-e hozzá, vagy töröl egy meglévő rendelést.
Adatszerkezeti projektek
Az adatstruktúrák tervezésekor több választási lehetőséget kell meghoznia. Az első választás az adattárolási mechanizmus, a második az adatok rendeltetésszerű felhasználása, a harmadik pedig a verziókövetelmények. Háromféleképpen tekinthetjük meg az adatszerkezet-terveket:
- A szolgáltatások adatokat kínálnak; Az adatok a relációs adatbázist tükrözik.
- Az adatokat objektumokhoz kell leképezni, és a szolgáltatások hozzáférést biztosítanak az objektumokhoz.
- A szolgáltatások által kínált adatoknak séma alapúnak kell lenniük.
Az adatfolyam-struktúra alapjául a három közül egyet kell választani a tervezési folyamat korai szakaszában. Sok vállalat rendelkezik olyan vállalati iránymutatással, amely három lehetőség valamelyikét írja elő az összes projektre vonatkozóan, de ahol lehetséges, újra kell értékelnie az egyes projektekre vonatkozó lehetőségeket, és kiválasztani az adott projekthez az optimális megközelítést.
Adattároló motor kiválasztása
Az alkalmazás megtervezésekor kétségtelenül meg kell terveznie valamilyen adattárat. A következő adattárak és adattárolási formák állnak rendelkezésre:
- Rekord
- app.config fájl
- xml fájlokat
- egyszerű szöveges fájlok
- Adatbázis
- üzenetsor
Minden üzletnek megvannak a maga egyedi jellemzői, és egyedi igényekre szabhatók.
Az adatfolyam tervezése
Adatáramlás az ADO.NET használatával
Az adatközpontú szolgáltatások alkalmazáslogikai rétegben való megvalósításával megtervezheti adatfolyamát az ADO.NET használatával. A .NET Framework osztálykönyvtár kiterjedt alkalmazásprogramozási felületet (API) biztosít a felügyelt kódban lévő adatok kezeléséhez. Az ADO.NET néven hivatkozott API a System.Data névtérben található. Az adathordozók és adattárolók teljes szétválasztása az ADO.NET fontos tervezési jellemzője. Az olyan osztályokat, mint a DataSet, DataTable és DataRow, úgy tervezték, hogy adatokat tároljanak, de nem tudják megőrizni, hogy az adatok honnan származnak. Adatforrás-agnosztikusnak számítanak. Egy külön osztálykészlet, például az SqlConnection, az SqlDataAdapter és az SqlCommand gondoskodik az adatforráshoz való csatlakozásról, az adatok lekéréséről, valamint a DataSet, DataTable és DataRow feltöltéséről. Ezek az osztályok olyan al-névterekben találhatók, mint a System.Data.Sql, System.Data.OleDB, System.Data.Oracle és így tovább. Attól függően, hogy melyik adatforráshoz szeretne csatlakozni, a megfelelő névtérben használhat osztályokat, és a használt termék hatókörétől függően azt tapasztalhatja, hogy ezek az osztályok több vagy kevesebb funkcionalitást kínálnak.
Mivel a DataSet nincs csatlakoztatva az adatforráshoz, meglehetősen sikeresen használható egy alkalmazás adatfolyamának kezelésére. A 8-5. ábra mutatja az adatáramlást ennek során.
Vessünk egy pillantást erre a projektre, és képzeljük el, hogy valaki bejelentkezett a könyvesboltjába, és három könyvet rendelt. A prezentációs réteg kezelte a bevásárlókosár állapotát. Az ügyfél készen áll a rendelés leadására, és minden szükséges adatot megad. A rendelés küldését választja. A weboldal az összes adatot egy DataSet-té alakítja, amely két DataTable-t tartalmaz, egyet a rendeléshez és egyet a rendeléshez; beszúr egy DataRow-t a rendeléshez; és beszúr három DataRow-t a rendelési sorokhoz. A weboldal ezután ismét megjeleníti ezeket az adatokat a felhasználónak, adatvezérlőket kötve a DataSethez, és megkérdezi. Biztos vagy benne? A felhasználó megerősíti a kérést, és az elküldésre kerül az alkalmazás logikai rétegére. Az alkalmazáslogikai réteg ellenőrzi a DataSet-et, hogy minden kötelező mezőnek van-e értéke, és ellenőrzi, hogy a felhasználó több mint 1000 US$-vel rendelkezik-e. 00 a fennálló számlákra. Ha minden jól megy, a DataSet átkerül az adatelérési réteghez, amely csatlakozik az adatbázishoz, és beszúrási utasításokat generál a DataSet információiból.
A DataSet ilyen módon történő használata gyors és hatékony módja egy alkalmazás létrehozásának, valamint a Framework Class Library és az ASP.NET azon képességének kihasználásának, hogy adatokat köthet különféle vezérlőkhöz, például a GridView-hoz egy adatkészlethez. Az egyszerű DataSet objektumok használata helyett használhat Typed DataSet objektumokat, és javíthatja a kódolási élményt a kód megvalósításával a megjelenítési rétegben, valamint az alkalmazáslogikai rétegben. Ennek a megközelítésnek az előnye egyben a megközelítés hátránya is. Az adatmodell kis változtatásai nem feltétlenül vezetnek ahhoz, hogy sok módszernek meg kell változtatnia az aláírását. Tehát a karbantartás szempontjából ez nagyon jól működik. Ha eszébe jut, hogy a prezentációs réteg nem feltétlenül felhasználói felület, akkor webszolgáltatás is lehet. És ha módosítja a DataSet definícióját, talán azért, mert átnevez egy mezőt az adatbázisban, akkor módosítja a szerződést, amelyre a webszolgáltatás előfizet. Ahogy el tudja képzelni, ez jelentős problémákhoz vezethet. Ez a forgatókönyv jól működik, ha a prezentációs réteg csak egy felhasználói felület, de a külső rendszerekhez vagy összetevőkhöz fűződő interfészeknél el kell rejtenie az alkalmazás belső működését, és az adatokat valami másra kell átalakítani, mint az adatmodell közvetlen klónjává. adatátviteli objektumokat (DTO) szeretne létrehozni.
Adatfolyam objektum relációs leképezés segítségével
Az ADO.NET-et használó adatfolyam az adatfolyam kezelésének nagyon adatközpontú megközelítése. Az adatok és a logika diszkrét. A spektrum másik vége az objektum-orientáltabb megközelítés. Itt osztályok jönnek létre az adatok és a viselkedés csoportosítására. A cél olyan osztályok meghatározása, amelyek utánozzák azon üzleti tartományban található adatokat és viselkedést, amelyhez az alkalmazást létrehozták. Az eredményt gyakran üzleti objektumnak nevezik. Az alkalmazást alkotó üzleti objektumok gyűjteményét tartománymodellnek nevezzük. Egyes fejlesztők azt állítják, hogy a gazdag tartománymodell jobb az összetettebb logika tervezésére. Egy ilyen állítást nehéz bizonyítani vagy cáfolni. Csak tudd, hogy van választásod, és rajtad múlik, hogy meg tudod-e választani.
A 8-6. ábra a 8-5. ábrához hasonló adatfolyamot mutat, azzal az eltéréssel, hogy most hozzáadta az objektumrelációs leképezési réteget, és a DataSet objektumokat különböző adathordozókra cserélte.
Most tegye ugyanazt lépésről lépésre, mint korábban; képzelje el, hogy valaki csatlakozott a könyvesboltjához, és három könyvet rendelt. A prezentációs réteg kezelte a bevásárlókosár állapotát. Az ügyfél készen áll a rendelés leadására, és minden szükséges adatot megad. A rendelés küldését választja. A weboldal az összes adatot DTO-vá alakítja, egy rendelés adatait tárolja három rendelési sorral, szükség szerint létrehozva az objektumokat. A weboldal ismét megjeleníti ezeket az adatokat a felhasználónak, az adat-összerendelés ellenőrzi a DTO-t az ObjectDataSource segítségével az ASP.NET 2.0-ban, és megkérdezi: Biztos vagy benne? A felhasználó megerősíti a választást, és a DTO elküldésre kerül az alkalmazás logikai rétegébe. Az alkalmazáslogikai réteg a DTO-t egy Order típusú üzleti objektummá alakítja, amelynek tulajdonsága három OrderLine objektumot tartalmaz. A rendelés módszere. A Validate() meghívásra kerül a rendelés érvényesítése és annak ellenőrzése, hogy minden kötelező mezőnek van-e értéke, és ellenőrzés történik annak megállapítására, hogy a felhasználónak van-e több mint R$ 1000,00 függőben lévő szelvénye. Ehhez a rendelés meghívja az Order.Customer.GetOutstandingBills() parancsot. Ha minden rendben, a Order.Save() metódus meghívódik. A kérés áthalad az objektum relációs leképezési rétegen, ahol a kérés és a kérés sorai egy DataSet-ben egy DataTable-re vannak leképezve, a DataSet pedig az adatelérési rétegnek kerül átadásra, amely csatlakozik az adatbázishoz és beszúrási utasításokat generál a DataSetben található információkat. Természetesen számos mód létezik az objektum-relációs leképezésre, de nem mindegyik tartalmazza a DataSet átalakítást. Egyesek közvetlenül hozzák létre az insert utasítást, de továbbra is az adatelérési réteget használják az utasítás végrehajtásához.
Amint látja, néhány átalakulás történik. A DTO-k használata azért szükséges, mert egy üzleti objektum valósítja meg a viselkedést, és a viselkedés változhat. A módosítások megjelenítési rétegre gyakorolt hatásának minimalizálása érdekében az adatokat az üzleti objektumból adatátviteli objektummá kell átalakítani. A Java nyelvben az adatátviteli objektumot gyakran érték objektumnak nevezik.
Az üzleti objektumokkal való munka nagy előnye, hogy valóban segít a kód rendszerezésében. Ha visszatekint egy összetett logikára, az általában nagyon jól olvasható, mert nagyon kevés a vízvezeték-kód. Hátránya, hogy a legtöbb adattár még mindig relációs, és az üzleti objektumok relációs adatokhoz való hozzárendelése meglehetősen bonyolulttá válhat.
séma alapú szolgáltatások
Az imént két ellentétet látott az adatáramlás kezelésében. Sok variáció lehetséges. Gyakori az a változat, amelyben egy adatkészletet használnak a felhasználói felület alapvető adathordozójaként az adatok tárolására, de külön sémákat (DTO) használnak a más rendszerekről meghívott webszolgáltatásokhoz. Az alkalmazási réteg a relációs adatokat előre meghatározott sémává alakítja. Ennek fő előnye, hogy a szolgáltatásra hivatkozó alkalmazások nem függenek az összetevő semmilyen belső megvalósításától. Ez nagyobb rugalmasságot tesz lehetővé a verziókezelésben, az interfészek visszamenőleges kompatibilitását, és lehetővé teszi az összetevő megvalósításának megváltoztatását a szolgáltatás felületének megváltoztatása nélkül.
Természetesen használhat üzleti objektumokat a webalkalmazásban, és megkerülheti a DTO-átalakítást, de ez általában csak akkor működik jól, ha az alkalmazás logikáját a webalkalmazással együtt implementálják. Ne feledje, hogy az Order.Save() meghívásához adatbáziskapcsolatra lesz szüksége. Hogy ez kívánatos-e, az Önön és valószínűleg a biztonsági igazgatóján múlik.