Toteutuslähestymistapafilosofioita
vesiputouksen lähestymistapa
Vesiputouslähestymistapa sovelluksen toteuttamiseen edellyttää, että suunnittelija kuulee yhden tai useamman loppukäyttäjäorganisaation edustajan ja kirjoittaa muistiin kaikki sovelluksen tekniset tiedot. Tyypillisesti spesifikaatiot toimitetaan joukossa toiminnallisia asiakirjoja tai käyttötapauksia, jotka on kirjoitettu siten, että loppukäyttäjä voi helposti lukea ja ymmärtää asiakirjoja.
Loppukäyttäjä allekirjoittaa nämä asiakirjat, ja sitten sovelluksen suunnitteleva tekninen suunnittelutiimi kerää asiakirjat luoden erilaisia artefakteja, kuten luokkamallikaavioita, tilakaavioita, toimintakaavioita ja tietomalleja. Tämän vaiheen tavoitteena on kirjoittaa kaikki niin yksityiskohtaisesti, että kehittäjällä ei ole vaikeuksia luoda tarvittavaa koodia. Suunnittelu luovutetaan virallisesti kehitystiimille ja testitiimille. Toimituksen jälkeen kehitystiimi aloittaa koodauksen ja testitiimi käyttää teknistä suunnittelua yhdessä käyttötapausten kanssa testitapausten ja testiskenaarioiden luomiseen.
Kun kehitystiimi on saanut koodauksen valmiiksi, koodi luovutetaan testitiimille. Testitiimi suorittaa suunnittelemansa testit vaatimusten ja yksityiskohtaisen suunnittelun perusteella. Kehitystiimi korjaa kaikki ongelmat. Kun testaus- ja korjausprosessi on valmis, sovellus toimitetaan loppukäyttäjälle hyväksymistestausta varten. Loppukäyttäjä suorittaa viimeisen tarkistuksen nähdäkseen, täyttääkö sovellus alkuperäiset vaatimukset. Jos hän hyväksyy, hän hyväksyy valmiin tuotteen ja projekti on valmis. Kun kehitystiimi on saanut koodauksen valmiiksi, koodi luovutetaan testitiimille.
Testitiimi suorittaa suunnittelemansa testit vaatimusten ja yksityiskohtaisen suunnittelun perusteella. Kehitystiimi korjaa kaikki ongelmat. Kun testaus- ja korjausprosessi on valmis, sovellus toimitetaan loppukäyttäjälle hyväksymistestausta varten. Loppukäyttäjä suorittaa viimeisen tarkistuksen nähdäkseen, täyttääkö sovellus alkuperäiset vaatimukset. Jos hän hyväksyy, hän hyväksyy valmiin tuotteen ja projekti on valmis. Kun kehitystiimi on saanut koodauksen valmiiksi, koodi luovutetaan testitiimille. Testitiimi suorittaa suunnittelemansa testit vaatimusten ja yksityiskohtaisen suunnittelun perusteella.
Kehitystiimi korjaa kaikki ongelmat. Kun testaus- ja korjausprosessi on valmis, sovellus toimitetaan loppukäyttäjälle hyväksymistestausta varten. Loppukäyttäjä suorittaa viimeisen tarkistuksen nähdäkseen, täyttääkö sovellus alkuperäiset vaatimukset. Jos hän hyväksyy, hän hyväksyy valmiin tuotteen ja projekti on valmis.
Loppukäyttäjä suorittaa viimeisen tarkistuksen nähdäkseen, täyttääkö sovellus alkuperäiset vaatimukset. Jos hän hyväksyy, hän hyväksyy valmiin tuotteen ja projekti on valmis. Loppukäyttäjä suorittaa viimeisen tarkistuksen nähdäkseen, täyttääkö sovellus alkuperäiset vaatimukset. Jos hän hyväksyy, hän hyväksyy valmiin tuotteen ja projekti on valmis.
Projektissa voi olla enemmän tai vähemmän vaiheita, kun käytetään vesiputouslähestymistapaa, mutta keskeinen piirre on kunkin vaiheen hyvin muodollinen aloitus ja loppu sekä hyvin muodolliset suoritukset.
Vesiputouslähestymistavan etuna on, että kustakin vaiheesta vastaavan tiimin vastuu on suurempi. On selvää, mitä heidän on toimitettava, milloin heidän on toimitettava se ja kenelle se on toimitettava. Usein kehitystiimin ei tarvitse olla vuorovaikutuksessa käyttäjän kanssa. Tämä voi olla erittäin hyödyllistä ulkoistaessa kehitystyötä toiseen maahan.
Vesiputouslähestymistavan suurin haittapuoli on, että ympäristössä, jossa kaikki on järjestetty hyvin muodollisesti, joustavuus reagoida muutoksiin vähenee. Muuttokin pitää järjestää. Hyvin harvat yritykset näyttävät tekevän tämän tehokkaasti, mikä usein johtaa yleiskustannusten huomattavaan nousuun. Hallitakseen projektin kustannuksia jotkut yritykset jopa viivyttävät vaatimuksiin muutoksia sovelluksen alkuperäiseen toimitukseen asti, jolloin ne toimittavat tehokkaasti sovelluksen, joka ei täytä loppukäyttäjän tarpeita.
ketterä kehitys
Monet pitkään jatkuneet ohjelmistokehitysprojektit ylittivät budjetin eivätkä toimittaneet tuotetta ajoissa. Ketterän ohjelmistokehitysfilosofian lähtökohtana on minimoida riskit kehittämällä ohjelmistoja lyhyissä aikalaatikoissa eli iteraatioissa, jotka kestävät tyypillisesti yhdestä neljään viikkoa. Jokainen iteraatio on kuin oma miniatyyri ohjelmistoprojektinsa ja sisältää kaikki tehtävät, joita tarvitaan uusien toimintojen lisäämiseen: suunnittelu, vaatimusanalyysi, suunnittelu, koodaus, testaus ja dokumentointi. Vaikka iteraatio ei välttämättä lisää tarpeeksi toimintoja tuotteen julkaisun takaamiseksi, ketterän ohjelmistoprojektin tavoitteena on pystyä julkaisemaan uusi ohjelmisto jokaisen iteraation lopussa. Jokaisen iteraation lopussa tiimi arvioi uudelleen projektin prioriteetit.
Ketterän ohjelmistokehityksen tavoitteena on saavuttaa asiakastyytyväisyys hyödyllisten ohjelmistojen nopealla ja jatkuvalla toimituksella; Pyrimme aina rakentamaan sitä, mitä asiakas tarvitsee; mieluummin mieluummin kuin vastustaa myöhäisiä muutoksia vaatimuksiin; sopeutua säännöllisesti muuttuviin olosuhteisiin; tiiviiseen ja päivittäiseen yhteistyöhön yrittäjien ja kehittäjien välillä, jossa kasvokkain keskustelu on paras kommunikaatiomuoto.
Ketterän ohjelmistokehityksen tärkein etu on joustavuus muutosten käsittelyssä pyrkien aina toimittamaan liiketoiminnan tarpeiden mukaan. Huono puoli on tietysti laajuuden, suunnittelun ja budjetoinnin hallinnan monimutkaistuminen. Toinen yleinen riski on vähäinen huomio (tekniseen) dokumentaatioon.
Inkrementaalinen kehitys
Inkrementaalinen ohjelmistokehitys on sekoitus ketterää ja vesiputouskehitystä. Sovellus suunnitellaan, toteutetaan ja testataan asteittain, jotta jokainen lisäys voidaan toimittaa loppukäyttäjälle. Projekti valmistuu vasta, kun viimeinen lisäys on valmis. Se pyrkii lyhentämään kaskadia määrittelemällä välivaiheita ja hyödyntämällä joitain ketterän kehityksen etuja. Edellisestä lisäyksestä saadun palautteen perusteella säätöjä voidaan tehdä seuraavan lisäyksen toimittamisen yhteydessä. Seuraava lisäys voi koostua uudesta koodista sekä aiemmin annettuun koodiin tehdyistä muutoksista.
Etuna on, että muodollisuudet pysyvät paikoillaan, mutta muutoksen hallinta helpottuu. Sovelluksen testaaminen ja käyttöönotto useaan kertaan maksaa enemmän kuin vain kerran.
Ohjelman kulkuohjaus
Ohjelman kulun ohjauksen lähestymistavan valitseminen on hyvin arkkitehtoninen tehtävä. Tavoitteena on luoda sovelluksestasi suunnitelma, jossa kun aloitat toimintojen ja koodin lisäämisen, kaikella näyttää olevan oma paikkansa. Jos olet koskaan tarkistanut tai kirjoittanut korkealaatuista koodia, ymmärrät tämän periaatteen.
Järjestäjän koodi
Ensimmäinen vaihe ohjelmakulun suunnittelussa on järjestää koodi luomalla joukko sääntöjä, jotka auttavat luomaan sovelluksen suunnitelman tai ääriviivat. Ylläpito, virheenkorjaus ja virheenkorjaus ovat helpompaa, koska koodi sijaitsee loogisessa paikassa. Kun olet tehnyt pohjatyön, voit valita lähestymistavan sovelluksesi logiikan toteuttamiseen.
Suunnittelukuvioilla tulisi olla tärkeä rooli ohjelmakulun ohjauksen suunnittelussa. Vuosien varrella on kirjoitettu paljon koodia ja monia ratkaisuja on suunniteltu toistuviin ongelmiin. Nämä ratkaisut on esitetty suunnittelumalleissa. Suunnittelumallin soveltaminen yleiseen ohjelmistosuunnitteluongelmaan auttaa sinua luomaan ratkaisuja, jotka ovat helposti tunnistettavissa ja jotka kollegasi voivat toteuttaa. Ainutlaatuiset ongelmat vaativat silti ainutlaatuisia ratkaisuja, mutta voit käyttää suunnittelumalleja apunasi niiden ratkaisemisessa.
Projektin luominen
kerroksia
Ensimmäinen askel on harkita loogisia kerroksia. Huomaa, että tasot eivät ole samoja kuin tasot, usein sekaisin tai jopa katsotaan samanlaisiksi.
kerrokset versus kerrokset
Tasot ovat kyse rajojen luomisesta koodillesi. Ylimmässä kerroksessa voi olla viittauksia alla olevien tasojen koodiin, mutta tasossa ei voi koskaan olla viittausta ylemmän tason koodiin. Tasot viittaavat tasojen fyysiseen jakautumiseen useiden tietokoneiden kesken. Esimerkiksi kolmikerroksisessa sovelluksessa käyttöliittymä on suunniteltu toimimaan pöytätietokoneessa, sovelluslogiikka on suunniteltu toimimaan sovelluspalvelimella ja tietokanta toimii tietokantapalvelimella. kerros voi koostua useista kerroksista.
Kuva 8-1: Kolmiportainen perusorganisaatio
Tasot viittaavat abstraktiotasoihin. Kuvassa 8-1 näkyvät kerrokset pätevät useimpiin sovelluksiin. Näitä tasoja kutsutaan myös kolmeksi päätasoksi, ja niillä voi olla useita muita nimiä. Esityskerroksen koodi voi pääsääntöisesti kutsua sovelluslogiikkakerroksen palveluita, mutta sovelluslogiikkakerros ei saa kutsua esityskerroksen menetelmää. Esityskerroksen ei tulisi koskaan kutsua suoraan tietojen käyttökerrosta, koska se ohittaisi sovelluslogiikkakerroksen toteuttamat vastuut. Tietojen käyttökerroksen ei tulisi koskaan kutsua sovelluslogiikkakerrosta.
Tasot ovat vain abstraktiota ja luultavasti helpoin tapa toteuttaa tasot on luoda kansioita projektiisi ja lisätä koodia sopivaan kansioon. Hyödyllisempi lähestymistapa olisi sijoittaa jokainen kerros erilliseen projektiin, jolloin luodaan erilliset kokoonpanot. Sovelluslogiikan sijoittamisen kirjastokokoonpanoon etuna on, että sen avulla voit luoda yksikkötestejä Microsoft Visual Studion tai NUnitin avulla logiikan testaamiseksi. Se luo myös joustavuutta kunkin kerroksen käyttöönoton valinnassa.
Fyysiset kerrokset
Yrityssovelluksessa odotat, että sinulla on useita asiakkaita samalle logiikalle. Itse asiassa, mikä tekee sovelluksesta yrityssovelluksen, on se, että se otetaan käyttöön kolmessa kerroksessa: asiakas, sovelluspalvelin ja tietokantapalvelin. Yrityksesi myyntiosaston luoma Microsoft Office Access -sovellus, vaikka se on myyntiosastolle erittäin tärkeä, ei ole yrityssovellus.
Huomaa, että sovelluslogiikka ja tiedon käyttökerrokset otetaan usein käyttöön yhdessä sovelluspalvelimella. Osa projektin suunnittelua on valita, käytetäänkö sovelluspalvelinta etä-.NET- tai Web-palveluilla. Kumman valitsetkin, lisäät koodin, jolla pääset helposti etäpalveluihin esitystasolla. Jos käytät verkkopalveluita sovelluspalvelimesi palveluihin, Visual Studio .NET tekee työn puolestasi ja luo välityspalvelimen koodin, joka toteuttaa automaattisesti etävälityspalvelimen mallin.
Kuvioiden lisääminen tasoihin
Kolme peruskerrosta tarjoavat korkean tason yleiskuvan. Lisätään joitakin rakenteellisia malleja luodaksesi vankan yritysarkkitehtuurin. Tulos näkyy kuvassa 8-2.
Keskity sovelluslogiikkakerrokseen. Kuva 8-2 osoittaa, että sovelluslogiikkaan päästään käyttämällä julkisivukuviota. Julkisivu on objekti, joka tarjoaa yksinkertaistetun käyttöliittymän suurempaan koodiin, kuten luokkakirjastoon. Julkisivu voi vähentää ulkoista koodiriippuvuutta kirjaston sisäisestä toiminnasta, koska useimmat koodit käyttävät julkisivua, mikä mahdollistaa enemmän joustavuutta järjestelmän kehittämisessä. Tätä varten julkisivu tarjoaa karkearakeisen rajapinnan kokoelmalle hienojakoisia esineitä.
päätösvirta
Ohjelmakulun ohjaus, joka tunnetaan myös nimellä päätösvirta, koskee sitä, kuinka suunnittelet palvelut sovelluslogiikkakerroksessa tai, kuten näit edellisessä kappaleessa, kuinka suunnittelet menetelmät julkisivussasi.
Palvelujesi järjestämiseen on kaksi tapaa:
- toimintasuuntautunut
- valtion ohjaama
Toimintakeskeinen lähestymistapa
Järjestämällä palveluja käyttäjän toimintoihin perustuen toteutat sovelluslogiikkaa tarjoamalla palveluita, joista jokainen käsittelee tietyn esityskerroksen pyynnön. Tämä tunnetaan myös tapahtumakoodimallina. Tämä lähestymistapa on suosittu, koska se on yksinkertainen ja näyttää hyvin luonnolliselta. Esimerkkejä menetelmistä, jotka noudattavat tätä lähestymistapaa, ovat BookStoreService.AddNewOrder(Tilausjärjestys) ja BookStoreService.CancelOrder(int orderId).
Toiminnon suorittamiseen tarvittava logiikka toteutetaan menetelmässä hyvin peräkkäin, mikä tekee koodista erittäin luettavan, mutta myös vaikeamman uudelleenkäyttöisen. Lisäsuunnittelukuvioiden, kuten pöytämoduulikuvion, käyttö voi auttaa lisäämään uudelleenkäytettävyyttä.
Valtiolähtöinen lähestymistapa
Sovelluksen päätösvirta on myös mahdollista toteuttaa huomattavasti tilalähtöisemmin. Sovelluspalvelimen tarjoamat palvelut ovat luonteeltaan yleisempiä, esimerkiksi BookStoreService.SaveOrder(Tilaustilaus). Tämä menetelmä tutkii tilauksen tilan ja päättää, lisätäänkö uusi tilaus vai peruutetaanko olemassa oleva tilaus.
Tietorakenneprojektit
Tietorakenteiden suunnittelussa on tehtävä useita valintoja. Ensimmäinen vaihtoehto on tietojen tallennusmekanismi, toinen on tietojen käyttötarkoitus ja kolmas on versiovaatimukset. Tietorakennesuunnitelmia voi tarkastella kolmella tavalla:
- Palvelut tarjoavat dataa; data on relaatiotietokannan heijastus.
- Tiedot on kartoitettava objekteihin ja palvelut tarjoavat pääsyn esineisiin.
- Palveluiden tarjoaman tiedon tulee olla skeemapohjaista.
Valitse jokin kolmesta tietovirtarakenteen perustaksi suunnitteluprosessin varhaisessa vaiheessa. Monilla yrityksillä on yrityksen ohje, joka määrää yhden kolmesta vaihtoehdosta kaikissa projekteissa, mutta mikäli mahdollista, sinun tulee arvioida kunkin projektin vaihtoehdot uudelleen ja valita kulloiseenkin projektiin optimaalinen lähestymistapa.
Tietojen tallennuskoneen valinta
Sovellusta suunniteltaessa joudut epäilemättä suunnittelemaan jonkinlaisen tietovaraston. Seuraavat varastot ja tietojen tallennusmuodot ovat saatavilla:
- Ennätys
- app.config-tiedosto
- xml-tiedostoja
- pelkkiä tekstitiedostoja
- Tietokanta
- viestijono
Jokaisella myymälällä on omat ainutlaatuiset ominaisuutensa ja ne voidaan räätälöidä tiettyjen vaatimusten mukaan.
Tietovirran suunnittelu
Tiedonkulku ADO.NETin avulla
Toteuttamalla tietokeskeisiä palveluita sovelluslogiikkakerroksessa suunnittelet tietovirtasi ADO.NETin avulla. .NET Framework -luokkakirjasto tarjoaa laajan sovellusohjelmointirajapinnan (API) hallitun koodin tietojen käsittelyyn. ADO.NET-nimellä kutsuttu API löytyy System.Data-nimiavaruudesta. Tietovälineiden ja tietovarastojen täydellinen erottaminen on tärkeä ADO.NETin suunnitteluominaisuus. Luokat, kuten DataSet, DataTable ja DataRow, on suunniteltu tallentamaan tietoja, mutta niillä ei ole tietoa siitä, mistä tiedot ovat peräisin. Heitä pidetään tietolähteen agnostikoina. Erillinen luokkien joukko, kuten SqlConnection, SqlDataAdapter ja SqlCommand, huolehtii yhteyden muodostamisesta tietolähteeseen, tietojen hakemisesta ja DataSet-, DataTable- ja DataRow-tietojen täyttämisestä. Nämä luokat sijaitsevat alinimiavaruuksissa, kuten System.Data.Sql, System.Data.OleDB, System.Data.Oracle ja niin edelleen. Riippuen siitä, mihin tietolähteeseen haluat muodostaa yhteyden, voit käyttää luokkia oikeassa nimiavaruudessa, ja käyttämäsi tuotteen laajuudesta riippuen huomaat, että nämä luokat tarjoavat enemmän tai vähemmän toimintoja.
Koska DataSet ei ole yhteydessä tietolähteeseen, sitä voidaan käyttää melko menestyksekkäästi sovelluksen tietovirran hallintaan. Kuva 8-5 näyttää tiedonkulun tätä tehtäessä.
Katsotaanpa tätä projektia ja kuvitellaan, että joku on kirjautunut kirjakauppaasi ja tilannut kolme kirjaa. Esityskerros hallitsi ostoskorin tilaa. Asiakas on valmis tekemään tilauksen ja toimittanut kaikki tarvittavat tiedot. Hän päättää lähettää tilauksen. Web-sivu muuntaa kaikki tiedot DataSetiksi, joka sisältää kaksi Datataulukkoa, yksi tilausta ja yksi tilausta varten; lisää tilaukseen DataRow'n; ja lisää kolme DataRowia tilausriveille. WWW-sivu näyttää sitten nämä tiedot takaisin käyttäjälle uudelleen, sitoa datasäätimet DataSetiin ja kysyy Oletko varma? Käyttäjä vahvistaa pyynnön ja se lähetetään sovelluksen loogiseen kerrokseen. Sovelluslogiikkakerros tarkistaa DataSetistä, onko kaikilla pakollisilla kentillä arvo, ja tarkistaa, onko käyttäjällä yli 1000 US$:tä. 00 maksamattomista laskuista. Jos kaikki sujuu hyvin, DataSet välitetään tietojen käyttökerrokseen, joka muodostaa yhteyden tietokantaan ja luo lisäyslausekkeita DataSet-tiedoista.
DataSetin käyttäminen tällä tavalla on nopea ja tehokas tapa rakentaa sovellus ja käyttää Framework Class Libraryn tehoa ja ASP.NETin kykyä sitoa tietoja erilaisiin ohjaimiin, kuten GridView DataSetiä vastaan. Yksinkertaisten DataSet-objektien sijaan voit käyttää Typed DataSet -objekteja ja parantaa koodauskokemusta toteuttamalla koodia esityskerrokseen sekä sovelluslogiikkakerrokseen. Tämän lähestymistavan etu on myös lähestymistavan haittapuoli. Pienet muutokset tietomalliin eivät välttämättä johda siihen, että monien menetelmien on muutettava allekirjoituksiaan. Huollon kannalta tämä siis toimii todella hyvin. Jos muistat, että esityskerros ei välttämättä ole käyttöliittymä, se voi olla myös verkkopalvelu. Ja jos muutat DataSetin määritelmää, ehkä siksi, että nimeät kentän uudelleen tietokannassa, muokkaat sopimusta, jonka verkkopalvelu tilaa. Kuten voit kuvitella, tämä voi johtaa merkittäviin ongelmiin. Tämä skenaario toimii hyvin, jos esityskerros on vain käyttöliittymä, mutta ulkoisten järjestelmien tai komponenttien liitäntöjen kohdalla sinun kannattaa piilottaa sovelluksesi sisäinen toiminta ja muuntaa tiedot joksikin muuksi kuin tietomallisi suoraksi klooniksi ja haluat luoda tiedonsiirtoobjekteja (DTO).
Tiedonkulku objektirelaatiomappauksella
ADO.NET-tiedonkulku on erittäin tietokeskeinen lähestymistapa tietovirran hallintaan. Data ja logiikka ovat erillisiä. Toisessa päässä on omaksuttu oliolähtöisempi lähestymistapa. Täällä luodaan luokat tietojen ja käyttäytymisen ryhmittelyä varten. Tavoitteena on määritellä luokat, jotka jäljittelevät dataa ja käyttäytymistä, joka löytyy liikealueelta, jota varten sovellus luotiin. Tulosta kutsutaan usein liiketoimintaobjektiksi. Sovelluksen muodostavien liiketoimintaobjektien kokoelmaa kutsutaan toimialuemalliksi. Jotkut kehittäjät väittävät, että rikas verkkotunnusmalli sopii paremmin monimutkaisemman logiikan suunnitteluun. Tällaista väitettä on vaikea todistaa tai kumota. Tiedä vain, että sinulla on valinnanvaraa ja sinun on tehtävä se.
Kuvassa 8-6 on samanlainen tietokulku kuin kuvassa 8-5, paitsi että nyt olet lisännyt objektien relaatiokartoituskerroksen ja korvannut DataSet-objektit eri tietovälineillä.
Tee nyt sama askel askeleelta kuin ennen; kuvittele, että joku oli yhteydessä kirjakauppaasi ja tilasi kolme kirjaa. Esityskerros hallitsi ostoskorin tilaa. Asiakas on valmis tekemään tilauksen ja toimittanut kaikki tarvittavat tiedot. Hän päättää lähettää tilauksen. Verkkosivu muuttaa kaikki tiedot DTO:ksi, jossa on tiedot yhdelle tilaukselle ja kolmella tilausrivillä luoden objektit tarpeen mukaan. Web-sivu näyttää nämä tiedot takaisin käyttäjälle vielä kerran, tietojen sidonta ohjaa DTO:ta ASP.NET 2.0:n ObjectDataSourcen avulla ja kysyy Oletko varma? Käyttäjä vahvistaa valinnan ja DTO lähetetään sovelluksen loogiseen kerrokseen. Sovelluslogiikkakerros muuttaa DTO:n tilaustyypin liikeobjektiksi, jonka ominaisuus sisältää kolme OrderLine-objektia. Tilausmenetelmä. Validate()-komentoa kutsutaan vahvistamaan tilaus ja varmistamaan, että kaikilla pakollisilla kentillä on arvo, ja tarkistetaan, onko käyttäjällä yli R$ 1 000,00 odottavia kuitteja. Tätä varten tilaus kutsuu Order.Customer.GetOutstandingBills(). Jos kaikki on hyvin, kutsutaan Order.Save()-metodia. Pyyntö kulkee objektin relaatiokartoituskerroksen läpi, jossa pyyntö ja pyynnön rivit kartoitetaan DataSetissä olevaan Datataulukkoon ja DataSet välitetään datan käyttökerrokseen, joka muodostaa yhteyden tietokantaan ja luo lisäyslausekkeita tietojoukon tiedot. On tietysti monia tapoja, joilla objekti-relaatiokartoitus voi tapahtua, mutta kaikki eivät sisällä muuntamista DataSetiksi. Jotkut luovat insert-käskyn suoraan, mutta käyttävät silti tiedon käyttökerrosta käskyn suorittamiseen.
Kuten näette, joitain muutoksia tapahtuu. DTO:iden käyttö on välttämätöntä, koska liiketoimintaobjekti toteuttaa käyttäytymisen ja käyttäytyminen voi muuttua. Minimoidaksesi näiden muutosten vaikutuksen esityskerrokseen sinun on muutettava tiedot liikeobjektista tiedonsiirtoobjektiksi. Javassa tiedonsiirtoobjektia kutsutaan usein arvoobjektiksi.
Liikeobjektien kanssa työskentelyn suuri etu on, että se todella auttaa järjestämään koodia. Jos katsot taaksepäin monimutkaista logiikkaa, se on yleensä hyvin luettavissa, koska LVI-koodia on hyvin vähän. Haittapuolena on, että useimmat tietovarastot ovat edelleen relaatiotietoja ja liiketoimintaobjektien yhdistäminen relaatiotietoihin voi olla melko monimutkaista.
skeemapohjaiset palvelut
Olet juuri nähnyt kaksi vastakohtaa tietovirran hallinnassa. Monet muunnelmat ovat mahdollisia. Yleinen on muunnos, jossa datajoukkoa käytetään käyttöliittymän perustietovälineenä tiedon tallentamiseen, mutta muista järjestelmistä kutsutuille verkkopalveluille käytetään erillisiä skeemoja (DTO). Sovelluskerros muuttaa relaatiotiedot ennalta määritetyksi skeemaksi. Tämän tärkein etu on, että mikään palveluun viittaava sovellus ei ole riippuvainen komponentin sisäisestä toteutuksesta. Tämä mahdollistaa enemmän joustavuutta versioinnissa, liitäntöjen taaksepäin yhteensopivuuden ja mahdollisuuden muuttaa komponentin toteutusta muuttamatta palvelun käyttöliittymää.
Tietysti voit käyttää verkkosovelluksessa liiketoimintaobjekteja ja ohittaa DTO-muunnoksen, mutta tämä toimii yleensä hyvin vain, jos sovelluslogiikka on toteutettu verkkosovelluksen mukana. Muista, että kutsuaksesi Order.Save() tarvitset tietokantayhteyden. Se, onko tämä toivottavaa, on sinun ja todennäköisesti turvallisuusjohtajasi päätettävissä.