Įgyvendinimo požiūrio filosofijos
Privažiavimas prie krioklio
Krioklio metodas įgyvendinant programą reikalauja, kad dizaineris konsultuotųsi su vienu ar daugiau galutinio vartotojo organizacijos atstovų ir užrašytų visas programos specifikacijas. Paprastai specifikacijos pateikiamos funkcinių dokumentų arba naudojimo atvejų rinkinyje, parašytose taip, kad galutinis vartotojas galėtų lengvai perskaityti ir suprasti dokumentus.
Galutinis vartotojas pasirašo šiuos dokumentus, o vėliau dokumentus surenka techninio projektavimo komanda, kurianti programą, sukurdama įvairius artefaktus, tokius kaip klasių modelių diagramos, būsenos diagramos, veiklos diagramos ir duomenų modeliai. Šio etapo tikslas – viską surašyti taip detaliai, kad kūrėjui nekiltų problemų kuriant reikiamą kodą. Yra oficialus dizaino perdavimas kūrimo komandai ir bandymų komandai. Po pristatymo kūrimo komanda pradeda kodavimą, o bandymų komanda naudoja techninį projektą kartu su naudojimo atvejais, kad sukurtų bandomuosius atvejus ir bandymo scenarijus.
Kūrimo komandai baigus koduoti, kodas perduodamas testavimo komandai. Testavimo komanda atlieka testus, kuriuos ji sukūrė pagal reikalavimus ir detalų projektą. Bet kokias problemas išspręs kūrimo komanda. Baigus testavimo ir ištaisymo procesą, paraiška perduodama galutiniam vartotojui priimtinumo testavimui. Galutinis vartotojas atlieka galutinį patikrinimą, ar programa atitinka pradinius reikalavimus. Patvirtinus, jis patvirtina gatavą produktą ir projektas baigiamas. Kūrimo komandai baigus koduoti, kodas perduodamas testavimo komandai.
Testavimo komanda atlieka testus, kuriuos ji sukūrė pagal reikalavimus ir detalų projektą. Bet kokias problemas išspręs kūrimo komanda. Baigus testavimo ir ištaisymo procesą, paraiška perduodama galutiniam vartotojui priimtinumo testavimui. Galutinis vartotojas atlieka galutinį patikrinimą, ar programa atitinka pradinius reikalavimus. Patvirtinus, jis patvirtina gatavą produktą ir projektas baigiamas. Kūrimo komandai baigus koduoti, kodas perduodamas testavimo komandai. Testavimo komanda atlieka testus, kuriuos ji sukūrė pagal reikalavimus ir detalų projektą.
Bet kokias problemas išspręs kūrimo komanda. Baigus testavimo ir ištaisymo procesą, paraiška perduodama galutiniam vartotojui priimtinumo testavimui. Galutinis vartotojas atlieka galutinį patikrinimą, ar programa atitinka pradinius reikalavimus. Patvirtinus, jis patvirtina gatavą produktą ir projektas baigiamas.
Galutinis vartotojas atlieka galutinį patikrinimą, ar programa atitinka pradinius reikalavimus. Patvirtinus, jis patvirtina gatavą produktą ir projektas baigiamas. Galutinis vartotojas atlieka galutinį patikrinimą, ar programa atitinka pradinius reikalavimus. Patvirtinus, jis patvirtina gatavą produktą ir projektas baigiamas.
Naudojant krioklio metodą, projektas gali turėti daugiau ar mažiau etapų, tačiau pagrindinė savybė yra labai formali kiekvieno etapo pradžia ir pabaiga su labai formaliais rezultatais.
Krioklio metodo pranašumas yra tas, kad už kiekvieną etapą atsakingos komandos atsakomybė yra didesnė. Aišku, ką jie turi pristatyti, kada turi pristatyti ir kam turi pristatyti. Dažnai kūrimo komandai nereikės bendrauti su vartotoju. Tai gali būti labai naudinga, kai plėtrą perkeliame į kitą šalį.
Pagrindinis krioklio požiūrio trūkumas yra tas, kad aplinkoje, kurioje viskas organizuota labai formaliai, sumažėja lankstumas reaguoti į pokyčius. Net kraustymąsi reikia organizuoti. Atrodo, kad labai nedaug įmonių tai daro efektyviai, todėl dažnai labai padidėja pridėtinės išlaidos. Siekdamos valdyti projekto išlaidas, kai kurios įmonės net atideda bet kokius reikalavimų pakeitimus iki pirminio programos pristatymo, efektyviai pristatydamos programą, kuri neatitinka galutinio vartotojo poreikių.
Judrus vystymasis
Daugelis ilgalaikių programinės įrangos kūrimo projektų viršijo biudžetą ir nesugebėjo pristatyti produkto laiku. Judraus programinės įrangos kūrimo filosofijos prielaida yra sumažinti riziką, kuriant programinę įrangą per trumpą laiką, vadinamą iteracijomis, kurios paprastai trunka nuo vienos iki keturių savaičių. Kiekviena iteracija yra tarsi atskiras miniatiūrinis programinės įrangos projektas ir apima visas užduotis, reikalingas naujoms funkcijoms išleisti: planavimą, reikalavimų analizę, projektavimą, kodavimą, testavimą ir dokumentaciją. Nors iteracija gali nepridėti pakankamai funkcijų, kad būtų garantuotas produkto išleidimas, judriu programinės įrangos projektu siekiama kiekvienos iteracijos pabaigoje išleisti naują programinę įrangą. Kiekvienos iteracijos pabaigoje komanda iš naujo įvertina projekto prioritetus.
Agilios programinės įrangos kūrimo tikslas – pasiekti klientų pasitenkinimą greitai ir nuolat tiekiant naudingą programinę įrangą; visada sieki sukurti tai, ko reikia klientui; sveikinti, o ne prieštarauti vėlyviems reikalavimų pakeitimams; reguliariai prisitaikyti prie besikeičiančių aplinkybių; glaudžiai, kasdien bendradarbiauti tarp verslininkų ir kūrėjų, kurių metu pokalbis akis į akį yra geriausia bendravimo forma.
Pagrindinis judrios programinės įrangos kūrimo privalumas yra lankstumas sprendžiant pokyčius, visada siekiant įgyvendinti verslo poreikius. Neigiamas aspektas, žinoma, yra sudėtingesnis valdymas, planavimas ir biudžeto sudarymas. Kita dažna rizika yra ribotas dėmesys (techninei) dokumentacijai.
Laipsniškas vystymasis
Laipsniškas programinės įrangos kūrimas yra judrus ir krioklio kūrimo derinys. Programa yra sukurta, įdiegta ir testuojama palaipsniui, kad kiekvienas priedas galėtų būti pristatytas galutiniam vartotojui. Projektas nebaigtas, kol nebaigtas paskutinis priedas. Juo siekiama sutrumpinti krioklį apibrėžiant tarpinius žingsnius ir naudojant kai kuriuos judrios plėtros pranašumus. Remiantis gautais atsiliepimais apie ankstesnį padidėjimą, galima atlikti koregavimus, kai pristatomas kitas padidėjimas. Kitas padidinimas gali būti sudarytas iš naujo kodo ir anksčiau pateikto kodo modifikacijų.
Privalumas tas, kad formalumai išlieka, tačiau pokyčių valdymas tampa lengvesnis. Programos bandymas ir diegimas kelis kartus kainuos daugiau nei vieną kartą.
Programos srauto valdymas
Programos srauto valdymo metodo pasirinkimas yra labai sudėtinga užduotis. Tikslas yra sukurti jūsų programos projektą, kuriame, kai tik pradėsite pridėti funkcijų ir kodo, viskas atrodo turi savo vietą. Jei kada nors peržiūrėjote ar parašėte aukštos kokybės kodą, suprantate šį principą
Organizacinis kodas
Pirmasis žingsnis kuriant programos srautą yra kodo sutvarkymas, taisyklių rinkinys, padedantis sukurti programos planą arba kontūrą. Priežiūra, derinimas ir klaidų taisymas bus lengviau, nes kodas yra vienoje loginėje vietoje. Atlikę parengiamuosius darbus, galite pasirinkti metodą, kaip įgyvendinti programos logiką.
Projektavimo modeliai turėtų vaidinti svarbų vaidmenį kuriant programos srauto valdymą. Bėgant metams buvo parašyta daug kodų ir sukurta daug sprendimų pasikartojančioms problemoms spręsti. Šie sprendimai yra nustatyti dizaino modeliuose. Projektavimo modelio taikymas bendrai programinės įrangos projektavimo problemai padės sukurti sprendimus, kuriuos lengvai atpažįsta ir gali įgyvendinti jūsų kolegos. Unikalioms problemoms vis tiek reikės unikalių sprendimų, tačiau galite naudoti dizaino modelius, kurie padės jas išspręsti.
Projekto kūrimas
Sluoksniai
Pirmas žingsnis yra apsvarstyti loginius sluoksnius. Atminkite, kad sluoksniai nėra tas pats, kas sluoksniai, dažnai painiojami arba netgi laikomi vienodais.
Sluoksniai prieš sluoksnius
Sluoksniai yra susiję su kodo ribų kūrimu. Viršutiniame sluoksnyje gali būti nuorodų į kodą žemiau esančiuose sluoksniuose, tačiau sluoksnis niekada negali turėti nuorodos į kodą aukščiau esančiame sluoksnyje. Sluoksniavimas susijęs su fiziniu sluoksnių paskirstymu keliuose kompiuteriuose. Pavyzdžiui, trijų pakopų taikomojoje programoje vartotojo sąsaja skirta veikti staliniame kompiuteryje, programos logika – programų serveryje, o duomenų bazė veikia duomenų bazės serveryje. skirtas duomenų sluoksnis ir kodas kiekvienas sluoksnis gali susidėti iš kelių sluoksnių.
8-1 pav. Pagrindinė trijų pakopų organizacija
Sluoksniai reiškia abstrakcijos lygius. 8-1 pav. parodyti sluoksniai tinka daugumai programų. Šie lygiai taip pat vadinami trimis pagrindiniais sluoksniais ir gali turėti keletą kitų pavadinimų. Paprastai pateikimo sluoksnyje esantis kodas gali iškviesti programos loginio sluoksnio paslaugas, tačiau programos loginis sluoksnis neturi iškviesti metodo pateikimo sluoksnyje. Pateikimo lygmuo niekada neturėtų tiesiogiai iškviesti duomenų prieigos sluoksnio, nes tai apeitų įsipareigojimus, kuriuos įgyvendina programos loginis sluoksnis. Prieigos prie duomenų sluoksnis niekada neturėtų skambinti programos logikos sluoksniu.
Sluoksniai yra tik abstrakcija ir tikriausiai lengviausias būdas įdiegti sluoksnius yra sukurti aplankus savo projekte ir pridėti kodą į atitinkamą aplanką. Naudingesnis būdas būtų įdėti kiekvieną sluoksnį į atskirą projektą, taip sukuriant atskirus mazgus. Programos logikos įtraukimo į bibliotekos rinkinį pranašumas yra tas, kad naudojant „Microsoft Visual Studio“ arba „NUnit“ bus galima sukurti vienetų testus, kad patikrintumėte logiką. Tai taip pat suteikia lankstumo pasirenkant, kur įdiegti kiekvieną sluoksnį.
Fiziniai sluoksniai
Įmonės programoje turėtumėte tikėtis turėti kelis klientus tai pačiai logikai. Iš tikrųjų tai, kas daro programą įmonės programa, yra tai, kad ji bus įdiegta trimis sluoksniais: kliento, programų serverio ir duomenų bazės serverio. „Microsoft Office Access“ programa, sukurta jūsų įmonės pardavimo skyriaus, nors ir labai svarbi pardavimų skyriui, nėra įmonės programa.
Atminkite, kad programų logika ir duomenų prieigos sluoksniai dažnai diegiami kartu programų serveryje. Dalis projekto kūrimo yra pasirinkimas, ar norite pasiekti programų serverį naudodami nuotolines .NET ar žiniatinklio paslaugas. Nepriklausomai nuo jūsų pasirinkimo, pridėsite kodą, kad galėtumėte lengvai pasiekti nuotolines paslaugas pristatymo sluoksnyje. Jei naudojate žiniatinklio paslaugas, kad pasiektumėte paslaugas savo programų serveryje, Visual Studio .NET atliks darbą už jus ir sugeneruos tarpinio serverio kodą, automatiškai pateikdama nuotolinio tarpinio serverio šablono įgyvendinimą.
Šablonų pridėjimas prie sluoksnių
Trys pagrindiniai sluoksniai suteikia aukšto lygio apžvalgą. Pridėkime keletą struktūrinių modelių, kad sukurtume tvirtą įmonės architektūrą. Rezultatas parodytas 8-2 pav.
Sutelkite dėmesį į programos loginį sluoksnį. 8-2 paveiksle parodyta, kad prieiga prie programos logikos yra naudojant fasado šabloną. Fasadas yra objektas, suteikiantis supaprastintą sąsają su didesniu kodo rinkiniu, pavyzdžiui, klasių biblioteka. Fasadas gali sumažinti išorinio kodo priklausomybę nuo bibliotekos vidinio veikimo, nes dauguma kodų naudoja fasadą, taip suteikiant daugiau lankstumo kuriant sistemą. Norėdami tai padaryti, fasadas suteiks grubią sąsają su smulkiagrūdžių objektų kolekcija.
Sprendimų srautas
Programos srauto valdymas, taip pat žinomas kaip sprendimų srautas, susijęs su tuo, kaip kuriate paslaugas savo programos loginiame lygmenyje arba, kaip matėte ankstesnėje pastraipoje, kaip kuriate metodus savo fasade.
Yra du būdai organizuoti savo paslaugas:
- Veiksmų orientuotas
- Orientuotas į valstybę
Į veiksmą orientuotas požiūris
Organizuodami paslaugas pagal vartotojo veiksmus, įgyvendinate programų logiką siūlydami paslaugas, kurių kiekviena apdoroja konkrečią užklausą iš pateikimo lygmens. Tai taip pat žinoma kaip operacijos scenarijaus šablonas. Šis metodas yra populiarus, nes jis yra paprastas ir atrodo labai natūralus. Metodų, kuriems taikomas šis metodas, pavyzdžiai yra BookStoreService.AddNewOrder(Užsakymo tvarka) ir BookStoreService.CancelOrder(int orderId).
Veiksmui atlikti reikalinga logika metode įgyvendinama labai nuosekliai, todėl kodas yra labai skaitomas, bet jį taip pat sunkiau pakartotinai naudoti. Naudojant papildomus dizaino modelius, pvz., lentelės modulio šabloną, galima padidinti pakartotinį naudojimą.
Į valstybę orientuotas požiūris
Taip pat galima įgyvendinti programos sprendimų srautą daug labiau į būseną orientuotu būdu. Programų serverio siūlomos paslaugos yra bendro pobūdžio, pavyzdžiui, BookStoreService.SaveOrder (Užsakymo užsakymas). Šis metodas apžvelgs užsakymo būseną ir nuspręs, ar pridėti naują užsakymą, ar atšaukti esamą užsakymą.
Duomenų struktūros projektai
Kurdami duomenų struktūras turite atlikti keletą pasirinkimų. Pirmasis pasirinkimas yra duomenų saugojimo mechanizmas, antrasis – numatytas duomenų panaudojimas, trečias – versijų kūrimo reikalavimai. Yra trys būdai, kaip peržiūrėti duomenų struktūros dizainą:
- Paslaugų pasiūlymo duomenys; duomenys yra reliacinės duomenų bazės atspindys.
- Duomenys turi būti susieti su objektais, o paslaugos suteikia prieigą prie objektų.
- Paslaugų siūlomi duomenys turi būti pagrįsti schema.
Vieną iš trijų kaip duomenų srauto struktūros pagrindą reikėtų pasirinkti ankstyvame projektavimo proceso etape. Daugelis įmonių turi įmonės gaires, pagal kurias visiems projektams numatyta viena iš trijų variantų, tačiau, jei įmanoma, turėtumėte iš naujo įvertinti kiekvieno projekto galimybes, pasirinkdami optimalų požiūrį į projektą.
Duomenų saugojimo variklio pasirinkimas
Kurdami savo programą, neabejotinai turėsite sukurti tam tikro tipo duomenų saugyklą. Galimos šios saugyklos ir duomenų saugojimo formos:
- Įrašas
- app.config failą
- XML failai
- paprasto teksto failai
- Duomenų bazė
- Pranešimų eilėje
Kiekviena parduotuvė turi savo unikalių savybių ir gali būti pritaikyta pagal specifinius reikalavimus.
Duomenų srauto projektavimas
Duomenų srautas naudojant ADO.NET
Įdiegę į duomenis orientuotas paslaugas programų logikos lygmenyje, suprojektuosite duomenų srautą naudodami ADO.NET. .NET Framework klasės bibliotekoje yra plati taikomųjų programų programavimo sąsaja (API), skirta valdyti duomenis valdomame kode. Vadinamas kaip ADO.NET, API galima rasti System.Data vardų srityje. Visiškas duomenų laikmenų ir duomenų saugyklų atskyrimas yra svarbi ADO.NET dizaino ypatybė. Tokios klasės kaip „DataSet“, „DataTable“ ir „DataRow“ yra skirtos duomenims saugoti, tačiau nepalieka žinių apie tai, iš kur gauti duomenys. Jie laikomi duomenų šaltinių agnostikais. Atskiras klasių rinkinys, pvz., „SqlConnection“, „SqlDataAdapter“ ir „SqlCommand“, pasirūpina prisijungimu prie duomenų šaltinio, duomenų gavimu ir duomenų rinkinio, duomenų lentelės ir „DataRow“ užpildymu. Šios klasės yra antrinėse vardų erdvėse, tokiose kaip System.Data.Sql, System.Data.OleDB, System.Data.Oracle ir pan. Priklausomai nuo to, prie kurio duomenų šaltinio norite prisijungti, galite naudoti klases tinkamoje vardų srityje ir, atsižvelgdami į naudojamo produkto apimtį, pastebėsite, kad šios klasės siūlo daugiau ar mažiau funkcijų.
Kadangi duomenų rinkinys nėra prijungtas prie duomenų šaltinio, jį gana sėkmingai galima naudoti duomenų srautui programoje valdyti. 8-5 paveiksle parodytas duomenų srautas tai darant.
Pažvelkime į šį projektą ir įsivaizduokime, kad kažkas prisijungė prie jūsų knygyno ir užsisakė tris knygas. Pristatymo sluoksnis valdė pirkinių krepšelio būseną. Klientas yra pasiruošęs pateikti užsakymą ir pateikė visus reikiamus duomenis. Jis nusprendžia siųsti užsakymą. Tinklalapis paverčia visus duomenis į duomenų rinkinį, kuriame yra dvi duomenų lentelės, viena užsakymui ir kita užsakymui; užsakymui įterpia DataRow; ir įterpia tris duomenų eilutes užsakymo eilutėms. Tada tinklalapyje šie duomenys vėl rodomi vartotojui, susiejant duomenų valdiklius su duomenų rinkiniu ir klausiant Ar esate tikras? Vartotojas patvirtina užklausą ir ji perduodama programos loginiam sluoksniui. Programos loginis sluoksnis patikrina duomenų rinkinį, kad pamatytų, ar visi privalomi laukai turi reikšmę, ir patikrina, ar vartotojas turi daugiau nei 1000 US$. 00 neapmokėtų sąskaitų. Jei viskas gerai, duomenų rinkinys perduodamas duomenų prieigos sluoksniui, kuris prisijungia prie duomenų bazės ir generuoja įterpimo sakinius iš duomenų rinkinio informacijos.
Tokiu būdu naudojant duomenų rinkinį yra greitas ir efektyvus būdas sukurti programą ir panaudoti Framework Class Library galią bei ASP.NET galimybę susieti duomenis su įvairiais valdikliais, pvz., „GridView“ su duomenų rinkiniu. Užuot naudoję paprastus duomenų rinkinio objektus, galite naudoti įvestus duomenų rinkinio objektus ir pagerinti kodavimo patirtį įdiegdami kodą pateikimo sluoksnyje ir programos loginiame sluoksnyje. Šio metodo privalumas yra ir metodo trūkumas. Dėl nedidelių duomenų modelio pakeitimų nebūtinai daugelis metodų turi pakeisti savo parašus. Taigi, kalbant apie priežiūrą, tai veikia tikrai gerai. Jei atsimenate, kad pateikimo sluoksnis nebūtinai yra vartotojo sąsaja, tai gali būti ir žiniatinklio paslauga. Ir jei pakeisite duomenų rinkinio apibrėžimą, galbūt todėl, kad pervardijate duomenų bazės lauką, modifikuojate sutartį. Kaip galite įsivaizduoti, tai gali sukelti didelių problemų. Šis scenarijus gerai veikia, jei pristatymo sluoksnis yra tik vartotojo sąsaja, bet sąsajoms su išorinėmis sistemomis ar komponentais norėsite paslėpti vidinį programos veikimą ir duomenis paversti kažkuo kitu, o ne tiesioginiu duomenų modelio klonu ir norėsite sukurti duomenų perdavimo objektus (DTO).
Duomenų srautas naudojant objektų reliacinį atvaizdavimą
Duomenų srautas naudojant ADO.NET yra labai į duomenis orientuotas duomenų srauto valdymo metodas. Duomenys ir logika yra diskretiški. Kitas spektro galas yra labiau į objektą orientuotas požiūris. Čia kuriamos klasės duomenims ir elgesiui grupuoti. Tikslas yra apibrėžti klases, kurios imituotų verslo domeno, kuriam buvo sukurta programa, duomenis ir elgesį. Rezultatas dažnai vadinamas verslo objektu. Verslo objektų, sudarančių programą, rinkinys vadinamas domeno modeliu. Kai kurie kūrėjai teigia, kad turtingas domeno modelis yra geresnis kuriant sudėtingesnę logiką. Tokį teiginį sunku įrodyti ar paneigti. Tiesiog žinokite, kad turite pasirinkimą, ir jūs turite tai padaryti.
8-6 paveiksle parodytas duomenų srautas, panašus į 8-5 pav., išskyrus tai, kad dabar pridėjote objektų santykio atvaizdavimo sluoksnį ir pakeitėte DataSet objektus skirtingomis duomenų laikmenomis.
Dabar atlikite tą patį žingsnis po žingsnio, kaip ir anksčiau; Įsivaizduokite, kad kažkas prisijungė prie jūsų knygyno ir užsisakė tris knygas. Pristatymo sluoksnis valdė pirkinių krepšelio būseną. Klientas yra pasiruošęs pateikti užsakymą ir pateikė visus reikiamus duomenis. Jis nusprendžia siųsti užsakymą. Tinklalapis visus duomenis paverčia DTO, kuriame saugomi vieno užsakymo duomenys ir trys užsakymo eilutės, sukuriant objektus pagal poreikį. Tinklalapis dar kartą parodo šiuos duomenis vartotojui, duomenų susiejimas kontroliuoja DTO naudojant ObjectDataSource ASP.NET 2.0 ir klausia Ar esate tikras? Vartotojas patvirtina pasirinkimą ir DTO pateikiamas programos loginiam sluoksniui. Programos loginis sluoksnis paverčia DTO į verslo objektą, kurio tipas yra Order su ypatybe, kurioje yra trys OrderLine objektai. Užsakymo metodas. Iškviečiamas patvirtinimas () patvirtinti užsakymą ir patikrinti, ar visi privalomi laukai turi reikšmę, taip pat patikrinama, ar vartotojas turi daugiau nei R$ 1 000,00 neapmokėtų sąskaitų faktūrų. Norėdami tai padaryti, užsakymas vadinsis Order.Customer.GetOutstandingBills(). Jei viskas gerai, iškviečiamas Order.Save() metodas. Užsakymas bus pateiktas objekto reliacinio susiejimo sluoksniui, kur užsakymo ir užsakymo eilutės susiejamos su duomenų lentele duomenų rinkinyje, o duomenų rinkinys perduodamas duomenų prieigos sluoksniui, kuris prisijungia prie duomenų bazės ir generuoja įterpimo instrukcijas iš informacijos, esančios duomenų rinkinyje. duomenų rinkinį. Žinoma, yra daug būdų, kuriais objektų santykinis atvaizdavimas gali įvykti, tačiau ne visi jie apims transformaciją į duomenų rinkinį. Kai kurie įterpimo sakinius sukurs tiesiogiai, bet vis tiek naudos duomenų prieigos sluoksnį, kad vykdytų tą sakinį.
Kaip matote, kai kurios transformacijos vyksta. DTO naudoti būtina, nes verslo objektas įgyvendina elgseną ir elgesys gali keistis. Norėdami sumažinti šių pakeitimų poveikį pateikimo sluoksniui, turite paversti duomenis iš verslo objekto į duomenų perdavimo objektą. Java kalboje duomenų perdavimo objektas dažnai vadinamas vertės objektu.
Didelis darbo su verslo objektais pranašumas yra tas, kad tai tikrai padeda tvarkyti kodą. Jei pažvelgsite į sudėtingos logikos dalį, ji paprastai yra labai įskaitoma, nes santechnikos kodo yra labai mažai. Neigiama yra tai, kad dauguma duomenų saugyklų vis dar yra reliacinės ir verslo objektų susiejimas su reliaciniais duomenimis gali būti gana sudėtingas.
schemomis pagrįstos paslaugos
Ką tik pastebėjote dvi priešingybes, kai kalbama apie duomenų srauto valdymą. Galimi įvairūs variantai. Dažnas yra variantas, kai duomenų rinkinys naudojamas kaip pagrindinė vartotojo sąsajos duomenų palaikymas duomenims saugoti, tačiau atskiros schemos (DTO) naudojamos žiniatinklio paslaugoms, iškviestoms iš kitų sistemų. Programos sluoksnis paverčia reliacinius duomenis į iš anksto nustatytą schemą. Pagrindinis privalumas yra tas, kad bet kuri programa, kuri nurodo paslaugą, nepriklauso nuo jokio vidinio komponento įgyvendinimo. Tai suteikia daugiau lankstumo kuriant versijas, atgalinį sąsajų suderinamumą ir galimybę keisti komponentų įgyvendinimą nekeičiant paslaugos sąsajos.
Žinoma, galite naudoti verslo objektus žiniatinklio programoje ir apeiti DTO transformaciją, tačiau tai paprastai gerai veikia tik tuo atveju, jei programos logika yra įdiegta kartu su žiniatinklio programa. Atminkite, kad norint iškviesti Order.Save(), jums reikės duomenų bazės ryšys. Ar tai pageidautina, priklauso nuo jūsų ir tikriausiai jūsų saugumo direktoriaus.