Ieviešanas pieejas filozofijas
Ūdenskrituma pieeja
Ūdenskrituma pieeja lietojumprogrammas ieviešanā paredz, ka dizainers konsultējas ar vienu vai vairākiem galalietotāju organizācijas pārstāvjiem un pieraksta visas lietojumprogrammas specifikācijas. Parasti specifikācijas tiek piegādātas funkcionālu dokumentu vai lietošanas gadījumu komplektā, kas rakstīts tā, lai galalietotājs varētu viegli lasīt un saprast dokumentus.
Galalietotājs paraksta šos dokumentus, un pēc tam dokumentus apkopo tehniskā projektēšanas komanda, kas izstrādā lietojumprogrammu, izveidojot dažādus artefaktus, piemēram, klašu modeļu diagrammas, stāvokļa diagrammas, darbību diagrammas un datu modeļus. Šīs fāzes mērķis ir visu uzrakstīt tik detalizēti, lai izstrādātājam nebūtu problēmu izveidot nepieciešamo kodu. Notiek oficiāla dizaina nodošana izstrādes komandai un testēšanas komandai. Pēc piegādes izstrādes komanda sāk kodēšanu, un testēšanas komanda izmanto tehnisko dizainu kopā ar lietošanas gadījumiem, lai izveidotu testa gadījumus un testa scenārijus.
Kad izstrādes komanda ir pabeigusi kodēšanu, kods tiek nodots testēšanas komandai. Testēšanas komanda veic tās izstrādātos testus, pamatojoties uz prasībām un detalizētu dizainu. Visas problēmas atrisinās izstrādes komanda. Kad testēšanas un atlīdzināšanas process ir pabeigts, pieteikums tiek nodots gala lietotājam pieņemšanas testēšanai. Galalietotājs veic pēdējo pārbaudi, lai noskaidrotu, vai lietojumprogramma atbilst sākotnējām prasībām. Ja tas ir apstiprināts, viņš apstiprina gatavo produktu un projekts ir pabeigts. Kad izstrādes komanda ir pabeigusi kodēšanu, kods tiek nodots testēšanas komandai.
Testēšanas komanda veic tās izstrādātos testus, pamatojoties uz prasībām un detalizētu dizainu. Visas problēmas atrisinās izstrādes komanda. Kad testēšanas un atlīdzināšanas process ir pabeigts, pieteikums tiek nodots gala lietotājam pieņemšanas testēšanai. Galalietotājs veic pēdējo pārbaudi, lai noskaidrotu, vai lietojumprogramma atbilst sākotnējām prasībām. Ja tas ir apstiprināts, viņš apstiprina gatavo produktu un projekts ir pabeigts. Kad izstrādes komanda ir pabeigusi kodēšanu, kods tiek nodots testēšanas komandai. Testēšanas komanda veic tās izstrādātos testus, pamatojoties uz prasībām un detalizētu dizainu.
Visas problēmas atrisinās izstrādes komanda. Kad testēšanas un atlīdzināšanas process ir pabeigts, pieteikums tiek nodots gala lietotājam pieņemšanas testēšanai. Galalietotājs veic pēdējo pārbaudi, lai noskaidrotu, vai lietojumprogramma atbilst sākotnējām prasībām. Ja tas tiek apstiprināts, viņš apstiprina gatavo produktu un projekts ir pabeigts.
Galalietotājs veic pēdējo pārbaudi, lai noskaidrotu, vai lietojumprogramma atbilst sākotnējām prasībām. Ja tas ir apstiprināts, viņš apstiprina gatavo produktu un projekts ir pabeigts. Galalietotājs veic pēdējo pārbaudi, lai noskaidrotu, vai lietojumprogramma atbilst sākotnējām prasībām. Ja tas ir apstiprināts, viņš apstiprina gatavo produktu un projekts ir pabeigts.
Izmantojot ūdenskrituma pieeju, projektam var būt vairāk vai mazāk posmu, taču galvenā iezīme ir ļoti formāls katras fāzes sākums un beigas ar ļoti formāliem rezultātiem.
Ūdenskrituma pieejas priekšrocība ir tā, ka par katru posmu atbildīgās komandas atbildība ir lielāka. Ir skaidrs, kas viņiem ir jāpiegādā, kad tas ir jāpiegādā un kam tas ir jāpiegādā. Bieži vien izstrādes komandai nav jāsazinās ar lietotāju. Tas var būt ļoti noderīgi, nododot izstrādes ārpakalpojumus citai valstij.
Galvenais ūdenskrituma pieejas trūkums ir tāds, ka vidē, kur viss tiek organizēts ļoti formāli, samazinās elastība reaģēt uz izmaiņām. Pat pārcelšanās ir jāorganizē. Šķiet, ka ļoti maz uzņēmumu to dara efektīvi, kā rezultātā bieži vien ievērojami palielinās pieskaitāmās izmaksas. Lai pārvaldītu projekta izmaksas, daži uzņēmumi pat aizkavē jebkādas prasību izmaiņas līdz lietojumprogrammas sākotnējai piegādei, efektīvi piegādājot lietojumprogrammu, kas neatbilst gala lietotāja vajadzībām.
Agila attīstība
Daudzi ilgstoši programmatūras izstrādes projekti pārsniedza budžetu un nepiegādāja produktu laikā. Agile programmatūras izstrādes filozofijas priekšnoteikums ir samazināt risku, izstrādājot programmatūru īsos laika periodos, ko sauc par iterācijām, kas parasti ilgst vienu līdz četras nedēļas. Katra iterācija ir kā savs miniatūras programmatūras projekts un ietver visus uzdevumus, kas nepieciešami jaunā funkcionalitātes pieauguma izlaišanai: plānošana, prasību analīze, projektēšana, kodēšana, testēšana un dokumentācija. Lai gan iterācija var nepievienot pietiekami daudz funkcionalitātes, lai garantētu produkta izlaišanu, elastīga programmatūras projekta mērķis ir katras iterācijas beigās izlaist jaunu programmatūru. Katras iterācijas beigās komanda atkārtoti novērtē projekta prioritātes.
Agile programmatūras izstrādes mērķis ir panākt klientu apmierinātību ar ātru un nepārtrauktu noderīgas programmatūras piegādi; vienmēr cenšas izveidot to, kas klientam vajadzīgs; atzinīgi vērtēt, nevis iebilst pret novēlotām prasību izmaiņām; regulāri pielāgoties mainīgajiem apstākļiem; ir cieša, ikdienas sadarbība starp uzņēmējiem un izstrādātājiem, kurā klātienes saruna ir labākais saziņas veids.
Agile programmatūras izstrādes galvenā priekšrocība ir elastība, risinot izmaiņas, vienmēr cenšoties nodrošināt atbilstību biznesa vajadzībām. Negatīvā puse, protams, ir tvēruma pārvaldības, plānošanas un budžeta veidošanas sarežģītības palielināšanās. Vēl viens izplatīts risks ir ierobežota uzmanība (tehniskajai) dokumentācijai.
Inkrementālā attīstība
Pakāpeniska programmatūras izstrāde ir elastīgas un ūdenskrituma izstrādes sajaukums. Lietojumprogramma tiek izstrādāta, ieviesta un pārbaudīta pakāpeniski, lai katru pieaugumu varētu piegādāt gala lietotājam. Projekts netiek pabeigts, kamēr nav pabeigts pēdējais solis. Tā mērķis ir saīsināt ūdenskritumu, nosakot starpposma pieaugumus un izmantojot dažas elastīgas attīstības priekšrocības. Pamatojoties uz atsauksmēm, kas saņemtas par iepriekšējo pieaugumu, nākamās palielināšanas laikā var veikt korekcijas. Nākamais palielinājums var sastāvēt no jauna koda, kā arī iepriekš sniegtā koda modifikācijām.
Priekšrocība ir tāda, ka formalitātes paliek spēkā, bet pārmaiņu vadība kļūst vienkāršāka. Lietojumprogrammas vairākkārtējas testēšanas un izvietošanas izmaksas būs lielākas nekā tikai vienu reizi.
Programmas plūsmas kontrole
Programmu plūsmas kontroles pieejas izvēle ir ļoti arhitektonisks uzdevums. Mērķis ir izveidot lietojumprogrammas projektu, kurā, tiklīdz sākat pievienot funkcionalitāti un kodu, šķiet, ka visam ir sava vieta. Ja kādreiz esat pārskatījis vai rakstījis augstas kvalitātes kodu, jūs saprotat šo principu
Organizācijas kods
Pirmais solis programmas plūsmas izstrādē ir koda organizēšana, izveidojot noteikumu kopu, kas palīdz izveidot lietojumprogrammas projektu vai kontūru. Apkope, atkļūdošana un kļūdu labošana būs vieglāka, jo kods atrodas vienā loģiskā vietā. Kad esat pabeidzis sagatavošanās darbus, varat izvēlēties pieeju lietojumprogrammas loģikas ieviešanai.
Projektēšanas modeļiem vajadzētu būt nozīmīgai programmas plūsmas kontroles izstrādē. Gadu gaitā ir rakstīts daudz koda un ir izstrādāti daudzi risinājumi atkārtotām problēmām. Šie risinājumi ir noteikti dizaina modeļos. Dizaina modeļa piemērošana izplatītai programmatūras projektēšanas problēmai palīdzēs jums izveidot risinājumus, kas ir viegli atpazīstami un kurus var ieviest jūsu vienaudži. Unikālām problēmām joprojām būs nepieciešami unikāli risinājumi, taču varat izmantot dizaina modeļus, lai palīdzētu jums tās atrisināt.
Projekta izveide
Slāņi
Pirmais solis ir apsvērt loģiskos slāņus. Ņemiet vērā, ka slāņi nav tas pats, kas slāņi, bieži tiek sajaukti vai pat tiek uzskatīti par vienādiem.
Slāņi pret slāņiem
Slāņi ir paredzēti robežu izveidošanai kodā. Augšējā slānī var būt atsauces uz kodu zemāk esošajos slāņos, taču slānī nekad nevar būt atsauces uz kodu augstākajā slānī. Slāņošana attiecas uz slāņu fizisko sadalījumu vairākos datoros. Piemēram, trīs līmeņu lietojumprogrammā lietotāja saskarne ir paredzēta darbībai galddatorā, lietojumprogrammu loģika ir paredzēta darbībai lietojumprogrammu serverī, un datu bāze darbojas datu bāzes serverī. Īpašs datu slānis un kods katrā slānis var sastāvēt no vairākiem slāņiem.
Attēls 8-1: Pamata trīs līmeņu organizācija
Slāņi attiecas uz abstrakcijas līmeņiem. Attēlā 8-1 parādītie slāņi attiecas uz lielāko daļu lietojumu. Šie līmeņi tiek saukti arī par trim galvenajiem slāņiem, un tiem var būt vairāki citi nosaukumi. Parasti kods prezentācijas slānī var izsaukt pakalpojumus lietojumprogrammas loģikas slānī, bet lietojumprogrammas loģikas slānis nedrīkst izsaukt prezentācijas slāņa metodi. Prezentācijas slānim nekad nevajadzētu tieši izsaukt datu piekļuves slāni, jo tādējādi tiktu apieti pienākumi, ko īsteno lietojumprogrammas loģikas slānis. Datu piekļuves slānim nekad nevajadzētu izsaukt lietojumprogrammas loģikas slāni.
Slāņi ir tikai abstrakcija, un, iespējams, vienkāršākais veids, kā ieviest slāņus, ir izveidot savā projektā mapes un pievienot kodu atbilstošajai mapei. Noderīgāka pieeja būtu ievietot katru slāni atsevišķā projektā, tādējādi veidojot atsevišķus mezglus. Lietojumprogrammas loģikas ievietošanas bibliotēkas komplektā priekšrocība ir tāda, ka tā ļaus jums izveidot vienību testus, izmantojot Microsoft Visual Studio vai NUnit, lai pārbaudītu loģiku. Tas arī rada elastību, izvēloties, kur izvietot katru slāni.
Fiziskie slāņi
Uzņēmuma lietojumprogrammā jums vajadzētu sagaidīt vairākus klientus vienai un tai pašai loģikai. Faktiski lietojumprogrammu par uzņēmuma lietojumprogrammu padara tas, ka tā tiks izvietota trīs slāņos: klients, lietojumprogrammu serveris un datu bāzes serveris. Jūsu uzņēmuma pārdošanas nodaļas izveidotā Microsoft Office Access lietojumprogramma, lai gan tā ir ļoti svarīga pārdošanas nodaļai, nav uzņēmuma lietojumprogramma.
Ņemiet vērā, ka lietojumprogrammu loģika un datu piekļuves slāņi lietojumprogrammu serverī bieži tiek izvietoti kopā. Daļa no projekta izstrādes ir izvēle, vai vēlaties piekļūt lietojumprogrammu serverim, izmantojot attālos .NET vai Web pakalpojumus. Neatkarīgi no jūsu izvēles jums būs jāpievieno kods, lai viegli piekļūtu attālajiem pakalpojumiem prezentācijas slānī. Ja izmantojat tīmekļa pakalpojumus, lai piekļūtu pakalpojumiem savā lietojumprogrammu serverī, Visual Studio .NET veiks darbu jūsu vietā un ģenerēs starpniekservera kodu, automātiski nodrošinot attālā starpniekservera modeļa ieviešanu.
Rakstu pievienošana slāņiem
Trīs pamata slāņi nodrošina augsta līmeņa pārskatu. Pievienosim dažus strukturālus modeļus, lai izveidotu stabilu uzņēmuma arhitektūru. Rezultāts ir parādīts 8-2 attēlā.
Koncentrējieties uz lietojumprogrammas loģikas slāni. Attēlā 8-2 parādīts, ka, lai piekļūtu lietojumprogrammu loģikai, tiek izmantots fasādes modelis. Fasāde ir objekts, kas nodrošina vienkāršotu saskarni lielākam koda kopumam, piemēram, klases bibliotēkai. Fasāde var samazināt ārējā koda atkarību no bibliotēkas iekšējās darbības, jo lielākā daļa koda izmanto fasādi, tādējādi nodrošinot lielāku elastību sistēmas izstrādē. Lai to izdarītu, fasāde nodrošinās rupji graudainu saskarni smalkgraudainu objektu kolekcijai.
Lēmumu plūsma
Programmas plūsmas vadība, kas pazīstama arī kā lēmumu plūsma, attiecas uz to, kā jūs plānojat pakalpojumus savā lietojumprogrammas loģikas slānī vai, kā redzējāt iepriekšējā rindkopā, kā jūs veidojat metodes savā fasādē.
Ir divas pieejas pakalpojumu organizēšanai:
- Orientēts uz darbību
- Uz valsti orientēts
Uz darbību orientēta pieeja
Organizējot pakalpojumus, pamatojoties uz lietotāja darbībām, jūs ieviešat lietojumprogrammu loģiku, piedāvājot pakalpojumus, no kuriem katrs apstrādā noteiktu pieprasījumu no prezentācijas slāņa. To sauc arī par darījuma skripta modeli. Šī pieeja ir populāra, jo tā ir vienkārša un šķiet ļoti dabiska. Metožu piemēri, kas izmanto šo pieeju, ir BookStoreService.AddNewOrder(Pasūtījuma pasūtījums) un BookStoreService.CancelOrder(int orderId).
Loģika, kas nepieciešama darbības veikšanai, metodē tiek ieviesta ļoti secīgi, padarot kodu ļoti lasāmu, bet arī grūtāk atkārtoti lietojamu. Izmantojot papildu dizaina modeļus, piemēram, tabulas moduļa modeli, var palielināt atkārtotu izmantošanu.
Uz valsti orientēta pieeja
Tāpat ir iespējams realizēt aplikācijas lēmumu plūsmu daudz valstij orientētāk. Lietojumprogrammu servera piedāvātie pakalpojumi pēc būtības ir vispārīgāki, piemēram, BookStoreService.SaveOrder (Pasūtīšanas pasūtījums). Šī metode apskatīs pasūtījuma statusu un izlems, vai pievienot jaunu pasūtījumu vai atcelt esošu pasūtījumu.
Datu struktūras projekti
Veidojot datu struktūras, jums ir jāizdara vairākas izvēles. Pirmā izvēle ir datu uzglabāšanas mehānisms, otrā ir datu paredzētais lietojums, bet trešā ir versijas prasības. Ir trīs veidi, kā aplūkot datu struktūras dizainus:
- Pakalpojumu piedāvājuma dati; dati ir relāciju datu bāzes atspoguļojums.
- Datiem jābūt kartētiem objektiem, un pakalpojumi nodrošina piekļuvi objektiem.
- Pakalpojumu piedāvātajiem datiem ir jābūt balstītiem uz shēmu.
Izvēloties vienu no trim par pamatu datu plūsmas struktūrai, vajadzētu veikt agrīnā projektēšanas procesa posmā. Daudziem uzņēmumiem ir uzņēmuma politika, kas paredz vienu no trim iespējām visiem projektiem, taču, ja iespējams, jums ir jāpārvērtē katra projekta iespējas, izvēloties ideālo pieeju konkrētajam projektam.
Datu glabāšanas programmas izvēle
Izstrādājot savu lietojumprogrammu, jums neapšaubāmi būs jāizstrādā sava veida datu krātuve. Ir pieejami šādi datu glabātuves un veidi:
- Ieraksts
- app.config failu
- XML faili
- vienkārša teksta faili
- Datu bāze
- Ziņojumu rinda
Katram veikalam ir savas unikālās īpašības, un to var pielāgot īpašām prasībām.
Datu plūsmas projektēšana
Datu plūsma, izmantojot ADO.NET
Lietojumprogrammas loģikas slānī ieviešot uz datiem orientētus pakalpojumus, jūs veidosit savu datu plūsmu, izmantojot ADO.NET. .NET Framework klases bibliotēka nodrošina plašu lietojumprogrammu saskarni (API) datu manipulēšanai pārvaldītajā kodā. Apzīmēts kā ADO.NET, API var atrast System.Data nosaukumvietā. Pilnīga datu nesēju un datu krātuvju atdalīšana ir svarīga ADO.NET dizaina iezīme. Klases, piemēram, DataSet, DataTable un DataRow, ir paredzētas datu glabāšanai, taču tās nesaglabā nekādas zināšanas par to, no kurienes dati iegūti. Viņi tiek uzskatīti par datu avotu agnostiķiem. Atsevišķa klašu kopa, piemēram, SqlConnection, SqlDataAdapter un SqlCommand, nodrošina savienojumu ar datu avotu, datu izgūšanu un DataSet, DataTable un DataRow aizpildīšanu. Šīs klases atrodas apakšnosaukumtelpās, piemēram, System.Data.Sql, System.Data.OleDB, System.Data.Oracle un tā tālāk. Atkarībā no tā, ar kuru datu avotu vēlaties izveidot savienojumu, varat izmantot klases pareizajā nosaukumvietā, un atkarībā no izmantotā produkta tvēruma jūs atklāsiet, ka šīs klases piedāvā vairāk vai mazāk funkcionalitātes.
Tā kā DataSet nav savienots ar datu avotu, to var diezgan veiksmīgi izmantot, lai pārvaldītu datu plūsmu lietojumprogrammā. Attēlā 8-5 ir parādīta datu plūsma, to darot.
Apskatīsim šo projektu un iedomāsimies, ka kāds ir pieteicies jūsu grāmatnīcā un pasūtījis trīs grāmatas. Prezentācijas slānis pārvaldīja iepirkumu groza stāvokli. Klients ir gatavs veikt pasūtījumu un ir sniedzis visus nepieciešamos datus. Viņš izvēlas nosūtīt pasūtījumu. Tīmekļa lapa pārveido visus datus par datu kopu, kurā ir divas datu tabulas, viena pasūtījumam un viena pasūtījumam; ievieto pieprasījumam DataRow; un ievieto trīs DataRows pasūtījuma rindām. Pēc tam tīmekļa lapa vēlreiz parāda šos datus lietotājam, kontrolē datu saistīšanu ar datu kopu un jautā Vai esat pārliecināts? Lietotājs apstiprina pieprasījumu, un tas tiek iesniegts lietojumprogrammas loģiskajam slānim. Lietojumprogrammas loģikas slānis pārbauda datu kopu, lai noskaidrotu, vai visiem obligātajiem laukiem ir vērtība, un veic pārbaudi, lai noskaidrotu, vai lietotājam ir vairāk nekā US$ 1000. 00 par neapmaksātiem rēķiniem. Ja viss ir kārtībā, datu kopa tiek nodota datu piekļuves slānim, kas savienojas ar datu bāzi un ģenerē ievietošanas instrukcijas, pamatojoties uz DataSet informāciju.
Šāda datu kopas izmantošana ir ātrs un efektīvs veids, kā izveidot lietojumprogrammu un izmantot Framework klases bibliotēkas jaudu un ASP.NET spēju saistīt datus ar vairākām vadīklām, piemēram, GridView pret datu kopu. Tā vietā, lai izmantotu vienkāršus DataSet objektus, varat izmantot Typed DataSet objektus un uzlabot kodēšanas pieredzi, ieviešot kodu prezentācijas slānī, kā arī lietojumprogrammas loģikas slānī. Šīs pieejas priekšrocība ir arī pieejas trūkums. Nelielas izmaiņas datu modelī ne vienmēr noved pie tā, ka daudzām metodēm ir jāmaina paraksti. Tātad apkopes ziņā tas darbojas patiešām labi. Ja atceraties, ka prezentācijas slānis ne vienmēr ir lietotāja interfeiss, tas var būt arī tīmekļa pakalpojums. Un, ja modificējat DataSet definīciju, iespējams, tāpēc, ka datubāzē pārdēvējat lauku, jūs modificējat līgumu, kas paraksta tīmekļa pakalpojums. Kā jau varat iedomāties, tas var radīt dažas būtiskas problēmas. Šis scenārijs darbojas labi, ja prezentācijas slānis ir tikai lietotāja interfeiss, bet saskarnēm ar ārējām sistēmām vai komponentiem vēlēsities paslēpt lietojumprogrammas iekšējo darbību un pārveidot datus par kaut ko citu, nevis tiešu datu modeļa klonu un jūs vēlaties izveidot datu pārsūtīšanas objektus (DTO).
Datu plūsma, izmantojot objektu relāciju kartēšanu
Datu plūsma, izmantojot ADO.NET, ir ļoti uz datiem orientēta pieeja datu plūsmas pārvaldīšanai. Dati un loģika ir diskrēti. Spektra otrā puse izmanto vairāk uz objektu orientētu pieeju. Šeit tiek izveidotas klases, lai grupētu datus un uzvedību. Mērķis ir definēt klases, kas atdarina datus un uzvedību, kas atrodama biznesa domēnā, kuram tika izveidota lietojumprogramma. Rezultāts bieži tiek saukts par biznesa objektu. Lietojumprogrammu veidojošo biznesa objektu kolekciju sauc par domēna modeli. Daži izstrādātāji apgalvo, ka bagātināts domēna modelis ir labāks, lai izstrādātu sarežģītāku loģiku. Šādu apgalvojumu ir grūti pierādīt vai atspēkot. Vienkārši ziniet, ka jums ir izvēle, un tas ir atkarīgs no jums.
Attēlā 8-6 ir parādīta datu plūsma, kas ir līdzīga 8-5. attēlā, izņemot to, ka tagad esat pievienojis objektu relāciju kartēšanas slāni un aizstājis DataSet objektus ar dažādiem datu nesējiem.
Tagad veiciet to pašu soli pa solim kā iepriekš; Iedomājieties, ka kāds ir pieteicies jūsu grāmatnīcā un pasūtījis trīs grāmatas. Prezentācijas slānis pārvaldīja iepirkumu groza stāvokli. Klients ir gatavs veikt pasūtījumu un ir sniedzis visus nepieciešamos datus. Viņš izvēlas nosūtīt pasūtījumu. Tīmekļa lapa pārveido visus datus par DTO, glabājot datus vienam pasūtījumam un ar trim pasūtījuma rindām, izveidojot objektus pēc vajadzības. Tīmekļa lapa vēlreiz parāda šos datus lietotājam, datu saistīšanas vadīklas pret DTO, izmantojot ASP.NET 2.0 ObjectDataSource, un jautā Vai esat pārliecināts? Lietotājs apstiprina izvēli, un DTO tiek iesniegts lietojumprogrammas loģiskajam slānim. Lietojumprogrammas loģikas slānis pārveido DTO par pasūtījuma tipa biznesa objektu ar rekvizītu, kas satur trīs OrderLine objektus. Pasūtīšanas metode. Validate() tiek izsaukts, lai apstiprinātu pasūtījumu un pārbaudītu, vai visiem obligātajiem laukiem ir vērtība, un tiek veikta pārbaude, lai noteiktu, vai lietotāja neapmaksātajos rēķinos ir vairāk nekā R$ 1000,00. Lai to izdarītu, pasūtījums tiks izsaukts Order.Customer.GetOutstandingBills(). Ja viss ir kārtībā, tiek izsaukta metode Order.Save(). Pasūtījums tiks iesniegts objekta relāciju kartēšanas slānī, kur pasūtījuma un secības rindas tiek kartētas uz datu tabulu datu kopā, un datu kopa tiek nodota datu piekļuves slānim, kas izveido savienojumu ar datu bāzi un ģenerē ievietošanas instrukcijas no informācijas. datu kopa. Protams, ir daudz veidu, kā var notikt objektu relāciju kartēšana, taču ne visos no tiem tiks iekļauta transformācija datu kopā. Daži ievietos priekšrakstus tieši, taču joprojām izmantos datu piekļuves slāni, lai izpildītu šo paziņojumu.
Kā redzat, notiek dažas pārvērtības. DTO izmantošana ir nepieciešama, jo biznesa objekts ievieš uzvedību un uzvedība var tikt mainīta. Lai samazinātu šo izmaiņu ietekmi uz prezentācijas slāni, ir jāpārveido dati no biznesa objekta par datu pārsūtīšanas objektu. Java valodā datu pārsūtīšanas objektu parasti sauc par vērtības objektu.
Liela priekšrocība darbā ar biznesa objektiem ir tā, ka tas patiešām palīdz sakārtot jūsu kodu. Ja atskatāties uz sarežģītu loģiku, tas parasti ir ļoti labi salasāms, jo tajā ir ļoti maz santehnikas koda. Negatīvā puse ir tāda, ka lielākā daļa datu krātuvju joprojām ir relācijas, un biznesa objektu kartēšana ar relāciju datiem var kļūt diezgan sarežģīta.
Uz shēmām balstīti pakalpojumi
Jūs tikko redzējāt divus pretstatus, kad runa ir par datu plūsmas pārvaldību. Iespējamas daudzas variācijas. Izplatīts ir variants, kurā datu kopa tiek izmantota kā lietotāja interfeisa pamata datu nesējs datu glabāšanai, bet atsevišķas shēmas (DTO) tiek izmantotas tīmekļa pakalpojumiem, kas izsaukti no citām sistēmām. Lietojumprogrammas slānis pārveido relāciju datus iepriekš noteiktā shēmā. Galvenā priekšrocība ir tā, ka jebkura lietojumprogramma, kas atsaucas uz pakalpojumu, nav atkarīga no komponenta iekšējās ieviešanas. Tas nodrošina lielāku elastību versiju veidošanā, saskarņu savietojamību un iespēju mainīt komponentu ieviešanu, nemainot pakalpojuma saskarni.
Protams, jūs varat izmantot biznesa objektus tīmekļa lietojumprogrammā un apiet DTO transformāciju, taču tas parasti darbojas labi tikai tad, ja lietojumprogrammas loģika ir ieviesta kopā ar tīmekļa lietojumprogrammu. Atcerieties, ka, lai izsauktu Order.Save(), jums būs nepieciešams datu bāzes savienojums. Tas, vai tas ir vēlams, ir atkarīgs no jums un, iespējams, jūsu drošības direktora.