Zbatimi i Logjikës së Projektit

Reklamat

Filozofitë e Qasjes së Zbatimit

afrimi me ujëvarë

Qasja Waterfall për zbatimin e një aplikacioni kërkon që një projektues të konsultohet me një ose më shumë përfaqësues të organizatës së përdoruesit fundor dhe të shkruajë të gjitha specifikimet e aplikacionit. Në mënyrë tipike, specifikimet vijnë në një grup dokumentesh funksionale ose raste përdorimi, të shkruara në mënyrë të tillë që përdoruesi përfundimtar të mund t'i lexojë dhe kuptojë lehtësisht dokumentet.

Përdoruesi përfundimtar i nënshkruan këto dokumente dhe dokumentet më pas mblidhen nga ekipi i projektimit teknik që harton aplikacionin, duke krijuar objekte të ndryshme si diagramet e modeleve të klasës, diagramet e gjendjes, diagramet e aktivitetit dhe modelet e të dhënave. Qëllimi i kësaj faze është të shkruajë gjithçka në mënyrë aq të detajuar që një zhvillues të mos ketë probleme për të krijuar kodin e nevojshëm. Ka një dorëzim zyrtar të dizajnit tek ekipi i zhvillimit dhe tek ekipi i testimit. Pas dorëzimit, ekipi i zhvillimit fillon kodimin dhe ekipi i testimit përdor dizajnin teknik në kombinim me rastet e përdorimit për të krijuar raste testimi dhe skenarë testimi.

Pasi ekipi i zhvillimit të përfundojë kodimin, kodi i dorëzohet ekipit të testimit. Ekipi i testimit kryen testet që ka projektuar në bazë të kërkesave dhe dizajnit të detajuar. Çdo problem do të rregullohet nga ekipi i zhvillimit. Pasi të përfundojë procesi i testimit dhe fiksimit, aplikacioni i dorëzohet përdoruesit fundor për testimin e pranimit. Përdoruesi përfundimtar kryen një kontroll përfundimtar për të parë nëse aplikacioni përputhet me kërkesat fillestare. Nëse miratohet, ai miraton produktin e përfunduar dhe projekti përfundon. Pasi ekipi i zhvillimit të përfundojë kodimin, kodi i dorëzohet ekipit të testimit.

Ekipi i testimit kryen testet që ka projektuar në bazë të kërkesave dhe dizajnit të detajuar. Çdo problem do të rregullohet nga ekipi i zhvillimit. Pasi të përfundojë procesi i testimit dhe fiksimit, aplikacioni i dorëzohet përdoruesit fundor për testimin e pranimit. Përdoruesi përfundimtar kryen një kontroll përfundimtar për të parë nëse aplikacioni përputhet me kërkesat fillestare. Nëse miratohet, ai miraton produktin e përfunduar dhe projekti përfundon. Pasi ekipi i zhvillimit të përfundojë kodimin, kodi i dorëzohet ekipit të testimit. Ekipi i testimit kryen testet që ka projektuar në bazë të kërkesave dhe dizajnit të detajuar.

Çdo problem do të rregullohet nga ekipi i zhvillimit. Pasi të përfundojë procesi i testimit dhe fiksimit, aplikacioni i dorëzohet përdoruesit fundor për testimin e pranimit. Përdoruesi përfundimtar kryen një kontroll përfundimtar për të parë nëse aplikacioni përputhet me kërkesat fillestare. Nëse miratohet, ai miraton produktin e përfunduar dhe projekti përfundon.

Përdoruesi përfundimtar kryen një kontroll përfundimtar për të parë nëse aplikacioni përputhet me kërkesat fillestare. Nëse miratohet, ai miraton produktin e përfunduar dhe projekti përfundon. Përdoruesi përfundimtar kryen një kontroll përfundimtar për të parë nëse aplikacioni përputhet me kërkesat fillestare. Nëse miratohet, ai miraton produktin e përfunduar dhe projekti përfundon.

Një projekt mund të ketë pak a shumë faza kur përdoret përqasja e ujëvarës, por tipari kryesor është fillimi dhe përfundimi shumë formal i çdo faze, me rezultate shumë formale.

Avantazhi i qasjes së ujëvarës është se përgjegjësia e ekipit përgjegjës për secilën fazë është më e madhe. Është e qartë se çfarë duhet të dorëzojnë, kur duhet ta dorëzojnë dhe kujt duhet t'ia dorëzojnë. Shpesh, ekipi i zhvillimit nuk do të ketë nevojë të ndërveprojë me përdoruesin. Kjo mund të jetë shumë e dobishme kur kontraktoni zhvillimin në një vend tjetër.

Disavantazhi kryesor i qasjes së ujëvarës është se, në një mjedis ku gjithçka është e organizuar në një mënyrë shumë formale, fleksibiliteti për t'iu përgjigjur ndryshimeve zvogëlohet. Edhe lëvizja duhet të organizohet. Shumë pak kompani duket se e bëjnë këtë në mënyrë efektive, duke rezultuar shpesh në një rritje të konsiderueshme të kostove të përgjithshme. Për të menaxhuar kostot e një projekti, disa kompani madje vonojnë çdo ndryshim të kërkesave deri në dorëzimin fillestar të aplikacionit, duke ofruar në mënyrë efektive një aplikacion që nuk i plotëson nevojat e përdoruesit përfundimtar.

zhvillimi i shkathët

Shumë projekte të gjata të zhvillimit të softuerit shkuan mbi buxhetin dhe nuk e dërguan produktin në kohë. Premisa e filozofisë së zhvillimit të softuerit të shkathët është të minimizojë rrezikun duke zhvilluar softuer në kuti kohore të shkurtra, të quajtura përsëritje, të cilat zakonisht zgjasin nga një deri në katër javë. Çdo përsëritje është si projekti i tij i softuerit në miniaturë dhe përfshin të gjitha detyrat e nevojshme për të çliruar rritjen e funksionalitetit të ri: planifikimin, analizën e kërkesave, dizajnimin, kodimin, testimin dhe dokumentacionin. Ndërsa një përsëritje mund të mos shtojë funksionalitet të mjaftueshëm për të garantuar lëshimin e produktit, një projekt softuer i shkathët synon të jetë në gjendje të lëshojë softuer të ri në fund të çdo përsëritjeje. Në fund të çdo përsëritjeje, ekipi rivlerëson prioritetet e projektit.

Qëllimi i zhvillimit të softuerit të shkathët është të arrijë kënaqësinë e klientit përmes ofrimit të shpejtë dhe të vazhdueshëm të softuerit të dobishëm; duke synuar gjithmonë të ndërtojë atë që i nevojitet klientit; mirëpresim, në vend që të kundërshtojmë, ndryshimet e vonuara të kërkesave; përshtaten rregullisht me rrethanat në ndryshim; të ketë bashkëpunim të ngushtë dhe të përditshëm ndërmjet sipërmarrësve dhe zhvilluesve, në të cilin biseda ballë për ballë është forma më e mirë e komunikimit.

Avantazhi kryesor i zhvillimit të softuerit të shkathët është fleksibiliteti në përballimin e ndryshimeve, duke synuar gjithmonë të ofrojë sipas nevojave të biznesit. Ana negative, natyrisht, është një rritje në kompleksitetin e menaxhimit të fushëveprimit, planifikimit dhe buxhetimit. Një tjetër rrezik i zakonshëm është vëmendja e kufizuar ndaj dokumentacionit (teknik).

Zhvillimi në rritje

Zhvillimi në rritje i softuerit është një përzierje e zhvillimit të shkathët dhe të ujëvarës. Një aplikacion është projektuar, zbatuar dhe testuar gradualisht në mënyrë që çdo rritje të mund t'i dorëzohet përdoruesit përfundimtar. Projekti nuk përfundon derisa të përfundojë rritja e fundit. Ai synon të shkurtojë kaskadën duke përcaktuar rritje të ndërmjetme dhe duke përdorur disa nga avantazhet e zhvillimit të shkathët. Bazuar në komentet e marra për një shtim të mëparshëm, mund të bëhen rregullime kur jepet shtimi tjetër. Rritja e radhës mund të përbëhet nga kodi i ri si dhe modifikime të kodit të dhënë më parë.

Avantazhi është se formalitetet mbeten në vend, por menaxhimi i ndryshimit bëhet më i lehtë. Kostoja e testimit dhe vendosjes së një aplikacioni disa herë do të jetë më e madhe sesa ta bësh atë vetëm një herë.

Kontrolli i rrjedhës së programit

Zgjedhja e një qasjeje për kontrollin e rrjedhës së programit është një detyrë shumë arkitekturore. Qëllimi është të krijoni një plan të aplikacionit tuaj ku, sapo të filloni të shtoni funksionalitet dhe kod, gjithçka duket se ka vendin e vet. Nëse keni rishikuar ose shkruar ndonjëherë kod me cilësi të lartë, ju e kuptoni këtë parim.

Kodi i organizatorit

Hapi i parë në hartimin e rrjedhës së programit është organizimi i kodit duke vendosur një sërë rregullash për të ndihmuar në krijimin e një plani ose skicë të aplikacionit. Mirëmbajtja, korrigjimi dhe rregullimi i gabimeve do të jenë më të lehta sepse kodi ndodhet në një vend logjik. Pasi të keni bërë bazën, mund të zgjidhni një qasje për zbatimin e logjikës së aplikacionit tuaj.

Modelet e projektimit duhet të luajnë një rol të rëndësishëm në hartimin e kontrollit të rrjedhës së programit. Me kalimin e viteve, janë shkruar shumë kode dhe janë krijuar shumë zgjidhje për problemet e përsëritura. Këto zgjidhje janë paraqitur në modelet e projektimit. Zbatimi i një modeli dizajni për një problem të zakonshëm të dizajnit të softuerit do t'ju ndihmojë të krijoni zgjidhje që janë lehtësisht të dallueshme dhe mund të zbatohen nga kolegët tuaj. Problemet unike do të kërkojnë ende zgjidhje unike, por ju mund të përdorni modele të projektimit për t'ju udhëhequr në zgjidhjen e tyre.

Krijimi i Projektit

shtresat

Hapi i parë është të merren parasysh shtresat logjike. Vini re se shtresat nuk janë të njëjta me shtresat, shpesh të ngatërruara apo edhe të konsideruara të njëjta.

shtresa kundrejt shtresave

Shtresat kanë të bëjnë me krijimin e kufijve në kodin tuaj. Shtresa e sipërme mund të ketë referenca për kodin në shtresat më poshtë, por një shtresë nuk mund të ketë kurrë një referencë për kodin në një shtresë sipër. Nivelet i referohen shpërndarjes fizike të niveleve nëpër kompjuterë të shumtë. Për shembull, në një aplikacion me tre nivele, UI është projektuar për të ekzekutuar në një kompjuter desktop, logjika e aplikacionit është krijuar për të ekzekutuar në një server aplikacioni dhe baza e të dhënave funksionon në një server të bazës së të dhënave. të të dhënave të dedikuara dhe kodit në secilin shtresa mund të përbëhet nga disa shtresa.

Figura 8-1: Organizimi bazë me tre nivele

Shtresat i referohen niveleve të abstraksionit. Shtresat e paraqitura në figurën 8-1 janë të vërteta për shumicën e aplikacioneve. Këto nivele referohen gjithashtu si tre shtresat kryesore dhe mund të kenë emra të ndryshëm. Si rregull, kodi në shtresën e prezantimit mund të thërrasë shërbimet në shtresën logjike të aplikacionit, por shtresa logjike e aplikacionit nuk duhet të thërrasë metodën në shtresën e prezantimit. Shtresa e prezantimit nuk duhet kurrë të thërrasë drejtpërdrejt shtresën e aksesit të të dhënave, pasi kjo do të anashkalonte përgjegjësitë e zbatuara nga shtresa logjike e aplikacionit. Shtresa e aksesit të të dhënave nuk duhet të thërrasë kurrë shtresën logjike të aplikacionit.

Shtresat janë thjesht një abstraksion dhe ndoshta mënyra më e lehtë për të zbatuar shtresat është të krijoni dosje në projektin tuaj dhe të shtoni kodin në dosjen e duhur. Një qasje më e dobishme do të ishte vendosja e secilës shtresë në një projekt të veçantë, duke krijuar kështu asamble të veçanta. Përfitimi i vendosjes së logjikës së aplikacionit tuaj në një asamble bibliotekë është se do t'ju lejojë të krijoni teste njësie, duke përdorur Microsoft Visual Studio ose NUnit, për të testuar logjikën. Ai gjithashtu krijon fleksibilitet në zgjedhjen se ku të vendoset çdo shtresë.

Shtresat Fizike

Në një aplikacion ndërmarrjeje, do të prisnit të keni klientë të shumtë për të njëjtën logjikë. Në fakt, ajo që e bën një aplikacion një aplikacion ndërmarrje është se ai do të vendoset në tre shtresa: klienti, serveri i aplikacionit dhe serveri i bazës së të dhënave. Aplikacioni Microsoft Office Access i krijuar nga departamenti i shitjeve të kompanisë suaj, megjithëse është shumë i rëndësishëm për departamentin e shitjeve, nuk është një aplikacion i korporatës.

Vini re se logjika e aplikacionit dhe shtresat e aksesit të të dhënave shpesh vendosen së bashku në serverin e aplikacionit. Një pjesë e projektimit të projektit është zgjedhja nëse do të aksesoni serverin e aplikacionit duke përdorur shërbime .NET ose Web në distancë. Cilado që të zgjidhni, do të shtoni disa kode për t'iu qasur lehtësisht shërbimeve në distancë në shtresën e prezantimit. Nëse jeni duke përdorur shërbime ueb për të aksesuar shërbimet në serverin tuaj të aplikacionit, Visual Studio .NET do të bëjë punën për ju dhe do të gjenerojë kodin e përfaqësuesit, duke siguruar automatikisht një zbatim të modelit të përfaqësuesit në distancë.

Shtimi i modeleve në shtresa

Tre shtresat bazë ofrojnë një pasqyrë të nivelit të lartë. Le të shtojmë disa modele strukturore për të krijuar një arkitekturë të fortë të ndërmarrjes. Rezultati është paraqitur në Figurën 8-2.

Përqendrohuni në shtresën logjike të aplikacionit. Figura 8-2 tregon se qasja në logjikën e aplikacionit është duke përdorur modelin e fasadës. Një fasadë është një objekt që ofron një ndërfaqe të thjeshtuar për një trup më të madh kodi, siç është biblioteka e klasës. Një fasadë mund të zvogëlojë varësitë e kodit të jashtëm nga funksionimi i brendshëm i një biblioteke, sepse shumica e kodeve përdorin fasadën, duke lejuar kështu më shumë fleksibilitet në zhvillimin e sistemit. Për ta bërë këtë, fasada do të sigurojë një ndërfaqe me grimca të trashë për një koleksion objektesh me grimca të imta.

rrjedha e vendimeve

Kontrolli i rrjedhës së programit, i njohur gjithashtu si rrjedha e vendimeve, ka të bëjë me mënyrën se si i dizajnoni shërbimet në shtresën logjike të aplikimit ose, siç e patë në paragrafin e mëparshëm, se si i dizajnoni metodat në fasadën tuaj.

Ekzistojnë dy mënyra për të organizuar shërbimet tuaja:

i orientuar në veprim
i drejtuar nga shteti

Qasje e orientuar në veprim

Duke organizuar shërbime të bazuara në veprimet e përdoruesit, ju po zbatoni logjikën e aplikacionit duke ofruar shërbime, secila prej të cilave trajton një kërkesë specifike nga shtresa e prezantimit. Kjo njihet gjithashtu si modeli i skriptit të transaksionit. Kjo qasje është e njohur sepse është e thjeshtë dhe duket shumë e natyrshme. Shembuj të metodave që ndjekin këtë qasje janë BookStoreService.AddNewOrder(porosi porosi) dhe BookStoreService.CancelOrder(int orderId).

Logjika e nevojshme për të kryer veprimin zbatohet në mënyrë shumë sekuenciale brenda metodës, duke e bërë kodin shumë të lexueshëm, por edhe më të vështirë për t'u ripërdorur. Përdorimi i modeleve shtesë të projektimit, si modeli i modulit të tabelës, mund të ndihmojë në rritjen e ripërdorimit.

Qasje e drejtuar nga shteti

Është gjithashtu e mundur të zbatohet rrjedha e vendimeve të aplikacionit në një mënyrë shumë më të orientuar drejt shtetit. Shërbimet e ofruara nga serveri i aplikacionit janë më të përgjithshme në natyrë, për shembull BookStoreService.SaveOrder(Order order). Kjo metodë do të ekzaminojë statusin e porosisë dhe do të vendosë nëse do të shtohet një porosi e re apo do të anulohet një porosi ekzistuese.

Projektet e strukturës së të dhënave

Ju duhet të bëni disa zgjedhje kur dizajnoni strukturat tuaja të të dhënave. Zgjedhja e parë është mekanizmi i ruajtjes së të dhënave, i dyti është përdorimi i synuar i të dhënave dhe i treti është kërkesat e versionit. Ekzistojnë tre mënyra për të parë dizajnet e strukturës së të dhënave:

Shërbimet ofrojnë të dhëna; të dhënat janë një pasqyrim i bazës së të dhënave relacionale.
Të dhënat duhet të hartohen me objekte dhe shërbimet sigurojnë qasje në objekte.
Të dhënat e ofruara nga shërbimet duhet të jenë të bazuara në skema.

Zgjedhja e një prej të treve si bazë për strukturën tuaj të rrjedhës së të dhënave duhet të bëhet në një fazë të hershme të procesit të projektimit. Shumë kompani kanë një udhëzues kompanie që mandaton një nga tre opsionet për të gjitha projektet, por aty ku është e mundur, ju duhet të rivlerësoni opsionet për secilin projekt, duke zgjedhur qasjen optimale për projektin në fjalë.

Zgjedhja e një motori të ruajtjes së të dhënave

Kur dizajnoni aplikacionin tuaj, padyshim që do t'ju duhet të krijoni një lloj ruajtjeje të dhënash. Dyqanet dhe format e mëposhtme të ruajtjes së të dhënave janë të disponueshme:

Regjistro
skedari app.config
skedarët xml
skedarë me tekst të thjeshtë
Baza e të dhënave
radhën e mesazheve

Çdo dyqan ka karakteristikat e veta unike dhe mund të përshtatet sipas kërkesave specifike.

Projektimi i rrjedhës së të dhënave

Rrjedha e të dhënave duke përdorur ADO.NET

Duke zbatuar shërbime me qendër të dhënat në shtresën logjike të aplikacionit, ju do të dizajnoni rrjedhën tuaj të të dhënave duke përdorur ADO.NET. Biblioteka e klasës .NET Framework ofron një ndërfaqe të gjerë programimi aplikacioni (API) për manipulimin e të dhënave në kodin e menaxhuar. I referuar si ADO.NET, API mund të gjendet në hapësirën e emrave System.Data. Ndarja e plotë e bartësve të të dhënave dhe ruajtjes së të dhënave është një veçori e rëndësishme e dizajnit të ADO.NET. Klasat si DataSet, DataTable dhe DataRow janë krijuar për të ruajtur të dhëna, por nuk mbajnë njohuri se nga kanë ardhur të dhënat. Ata konsiderohen si agnostikë të burimit të të dhënave. Një grup i veçantë klasash, të tilla si SqlConnection, SqlDataAdapter dhe SqlCommand, kujdesen për lidhjen me një burim të dhënash, marrjen e të dhënave dhe plotësimin e DataSet, DataTable dhe DataRow. Këto klasa janë të vendosura në nën-hapësirat e emrave si System.Data.Sql, System.Data.OleDB, System.Data.Oracle etj. Në varësi të burimit të të dhënave me të cilin dëshironi të lidheni, mund të përdorni klasa në hapësirën e duhur të emrave dhe në varësi të fushës së produktit që po përdorni, do të zbuloni se këto klasa ofrojnë pak a shumë funksionalitet.

Meqenëse DataSet nuk është i lidhur me burimin e të dhënave, ai mund të përdoret me mjaft sukses për të menaxhuar rrjedhën e të dhënave në një aplikacion. Figura 8-5 tregon rrjedhën e të dhënave kur e bëni këtë.

Le t'i hedhim një sy këtij projekti dhe të imagjinojmë që dikush ka hyrë në librarinë tuaj dhe ka porositur tre libra. Shtresa e prezantimit menaxhoi gjendjen e karrocës së blerjeve. Klienti është i gatshëm të bëjë porosinë dhe ka dhënë të gjitha të dhënat e nevojshme. Ai zgjedh të dërgojë porosinë. Faqja e internetit i transformon të gjitha të dhënat në një grup të dhënash që përmban dy tabela të dhënash, një për porosi dhe një për porosi; fut një DataRow për porosinë; dhe fut tre DataRows për linjat e rendit. Faqja e internetit më pas i shfaq këto të dhëna përsëri te përdoruesi, duke lidhur kontrollet e të dhënave me grupin e të dhënave dhe duke pyetur A jeni i sigurt? Përdoruesi konfirmon kërkesën dhe ajo dorëzohet në shtresën logjike të aplikacionit. Shtresa logjike e aplikacionit kontrollon DataSet për të parë nëse të gjitha fushat e kërkuara kanë një vlerë dhe kryen një kontroll për të parë nëse përdoruesi ka më shumë se 1000 US$. 00 për faturat e papaguara. Nëse gjithçka shkon mirë, DataSet kalon në shtresën e aksesit të të dhënave, e cila lidhet me bazën e të dhënave dhe gjeneron deklarata insert nga informacioni i DataSet.

Përdorimi i DataSet në këtë mënyrë është një mënyrë e shpejtë dhe efikase për të ndërtuar një aplikacion dhe për të përdorur fuqinë e Framework Class Library dhe aftësinë e ASP.NET për të lidhur të dhënat me kontrolle të ndryshme si GridView kundrejt një DataSet. Në vend që të përdorni objekte të thjeshta DataSet, mund të përdorni objektet Typed DataSet dhe të përmirësoni përvojën e kodimit duke zbatuar kodin në shtresën e prezantimit si dhe në shtresën logjike të aplikacionit. Avantazhi i kësaj qasjeje është edhe disavantazhi i qasjes. Ndryshimet e vogla në modelin e të dhënave nuk çojnë domosdoshmërisht në shumë metoda që duhet të ndryshojnë nënshkrimet e tyre. Pra, për sa i përket mirëmbajtjes, kjo funksionon vërtet mirë. Nëse mbani mend se shtresa e prezantimit nuk është domosdoshmërisht një ndërfaqe përdoruesi, ajo mund të jetë gjithashtu një shërbim në internet. Dhe nëse modifikoni përkufizimin e DataSet, ndoshta sepse po riemërtoni një fushë në bazën e të dhënave, atëherë po modifikoni kontratën në të cilën është abonuar shërbimi në internet. Siç mund ta imagjinoni, kjo mund të çojë në disa çështje të rëndësishme. Ky skenar funksionon mirë nëse shtresa e prezantimit është vetëm një ndërfaqe përdoruesi, por për ndërfaqet me sistemet ose komponentët e jashtëm, do të dëshironi të fshehni funksionet e brendshme të aplikacionit tuaj dhe t'i transformoni të dhënat në diçka tjetër përveç një klon të drejtpërdrejtë të modelit tuaj të të dhënave dhe ju do të dëshironi të krijoni Objekte të Transferimit të të Dhënave (DTO).

Rrjedha e të dhënave duke përdorur hartën relacionale të objektit

Rrjedha e të dhënave duke përdorur ADO.NET është një qasje shumë e përqendruar te të dhënat për menaxhimin e rrjedhës së të dhënave. Të dhënat dhe logjika janë diskrete. Ana tjetër e spektrit është duke marrë një qasje më të orientuar nga objekti. Këtu krijohen klasa për të grupuar të dhënat dhe sjelljen. Qëllimi është të përcaktohen klasa që imitojnë të dhënat dhe sjelljen e gjetur në domenin e biznesit për të cilin është krijuar aplikacioni. Rezultati shpesh referohet si një objekt biznesi. Koleksioni i objekteve të biznesit që përbëjnë aplikacionin quhet modeli i domenit. Disa zhvillues pretendojnë se një model i pasur domeni është më i mirë për të hartuar logjikë më komplekse. Është e vështirë të vërtetosh apo të hedhësh poshtë një pretendim të tillë. Vetëm dijeni se ju keni një zgjedhje dhe varet nga ju që ta bëni atë.

Figura 8-6 tregon një rrjedhë të dhënash të ngjashme me Figurën 8-5, përveç se tani keni shtuar shtresën e hartës relacionale të objektit dhe keni zëvendësuar objektet e DataSet me bartës të ndryshëm të të dhënave.

Tani bëni të njëjtin hap pas hapi si më parë; imagjinoni që dikush është lidhur me librarinë tuaj dhe ka porositur tre libra. Shtresa e prezantimit menaxhoi gjendjen e karrocës së blerjeve. Klienti është i gatshëm të bëjë porosinë dhe ka dhënë të gjitha të dhënat e nevojshme. Ai zgjedh të dërgojë porosinë. Faqja e internetit i kthen të gjitha të dhënat në një DTO, duke mbajtur të dhëna për një porosi dhe me tre linja porosie, duke krijuar objektet sipas nevojës. Faqja e internetit i shfaq këto të dhëna përsëri tek përdoruesi, kontrollon lidhjen e të dhënave kundër DTO-së duke përdorur ObjectDataSource në ASP.NET 2.0 dhe pyet A je i sigurt? Përdoruesi konfirmon zgjedhjen dhe DTO dorëzohet në shtresën logjike të aplikacionit. Shtresa logjike e aplikacionit transformon DTO në një objekt biznesi të tipit Order me një veti që të përmbajë tre objekte OrderLine. Metoda e porosisë. Validate() thirret për të vërtetuar urdhrin dhe për të verifikuar që të gjitha fushat e kërkuara kanë një vlerë dhe bëhet një kontroll për të identifikuar nëse përdoruesi ka më shumë se R$ 1,000.00 në rrëshqitje në pritje. Për ta bërë këtë, porosia do të thërrasë Order.Customer.GetOutstandingBills(). Nëse gjithçka është mirë, thirret metoda Order.Save(). Kërkesa do të kalojë përmes shtresës së hartës relacionale të objektit, ku kërkesa dhe rreshtat e kërkesës janë hartuar në një DataTable në një grup të dhënash, dhe grupi i të dhënave kalon në shtresën e aksesit të të dhënave, e cila lidhet me bazën e të dhënave dhe gjeneron deklarata insert nga informacionin në grupin e të dhënave. Ka, sigurisht, shumë mënyra në të cilat mund të ndodhë hartëzimi i marrëdhënieve objekt, por jo të gjitha do të përfshijnë transformimin në një grup të dhënash. Disa do të krijojnë drejtpërdrejt deklaratën e futjes, por ende përdorin shtresën e aksesit të të dhënave për të ekzekutuar atë deklaratë.

Siç mund ta shihni, ndodhin disa transformime. Përdorimi i DTO-ve është i nevojshëm sepse një objekt biznesi zbaton sjelljen dhe sjellja është subjekt ndryshimi. Për të minimizuar ndikimin e këtyre ndryshimeve në shtresën e prezantimit, duhet t'i transformoni të dhënat nga objekti i biznesit dhe në një objekt transferimi të të dhënave. Në Java, objekti i transferimit të të dhënave shpesh referohet si objekti i vlerës.

Një avantazh i madh i punës me objekte biznesi është se ndihmon vërtet në organizimin e kodit tuaj. Nëse shikoni prapa në një pjesë komplekse të logjikës, zakonisht është shumë e lexueshme sepse ka shumë pak kod hidraulik. Ana negative është se shumica e dyqaneve të të dhënave janë ende relacionale dhe hartëzimi i objekteve të biznesit me të dhënat relacionale mund të bëhet mjaft kompleks.

shërbime të bazuara në skema

Sapo keni parë dy të kundërta kur bëhet fjalë për menaxhimin e rrjedhës së të dhënave. Shumë variacione janë të mundshme. Një i zakonshëm është varianti në të cilin një grup të dhënash përdoret si bartësi bazë i të dhënave të UI për ruajtjen e të dhënave, por skemat e veçanta (DTO) përdoren për shërbimet e uebit të thirrura nga sisteme të tjera. Shtresa e aplikimit transformon të dhënat relacionale në një skemë të paracaktuar. Avantazhi kryesor i kësaj është se çdo aplikacion që i referohet shërbimit nuk varet nga asnjë lloj zbatimi i brendshëm i komponentit. Kjo lejon më shumë fleksibilitet në versionim, përputhshmëri të prapambetur të ndërfaqeve dhe aftësinë për të ndryshuar zbatimin e komponentit pa ndryshuar ndërfaqen e shërbimit.

Sigurisht, ju mund të përdorni objekte biznesi në aplikacionin në internet dhe të anashkaloni transformimin DTO, por kjo zakonisht funksionon mirë vetëm nëse logjika e aplikacionit zbatohet së bashku me aplikacionin në internet. Mos harroni se për të thirrur Order.Save() do t'ju duhet një lidhje me bazën e të dhënave. Nëse kjo është e dëshirueshme varet nga ju dhe ndoshta drejtori juaj i sigurisë.