Šį pranešimą paskutinį kartą redagavo Vasara 2017-9-27 15:32
Šis straipsnis yra trumpa istorija, imituojanti klausimus ir atsakymus, o autorius humoristiniu stiliumi trumpai analizuoja architektų darbą: Noriu būti programinės įrangos architektu. Tai puikus pasirinkimas jauniems programinės įrangos kūrėjams. Noriu vadovauti komandai ir priimti svarbius sprendimus dėl duomenų bazių ir sistemų, žiniatinklio serverių ir kt. O, tada jūs visai nenorite būti programinės įrangos architektu. Žinoma, norėjau būti svarbių sprendimų priėmėjas. Tai gerai, bet jūs neįtraukiate svarbių sprendimų į savo sąrašą, kurie yra nereikšmingi sprendimai. Ką turi galvoje? Ar sakote, kad duomenų bazės nėra svarbūs sprendimai, ar žinote, kiek joms išleidžiame? Galbūt tai kainuoja per daug. Tačiau duomenų bazės nėra vienas iš svarbių sprendimų. Kaip galite tai pasakyti? Duomenų bazė yra sistemos šerdis, kurioje visi duomenys yra sisteminami, klasifikuojami, indeksuojami ir pasiekiami. Be duomenų bazės nebūtų sistemos. Duomenų bazė yra tik IO įrenginys, kuris suteikia naudingų klasifikavimo, užklausų ir informacijos ataskaitų teikimo įrankių, tačiau tai tik pagalbinės sistemos architektūros funkcijos. Pagalba? Tai yra pasipiktinimas. Teisingai, tai pagalbinė. Sistemos veiklos taisyklės gali pasinaudoti kai kuriais iš šių įrankių, tačiau tie įrankiai nėra būdingi atitinkamoms veiklos taisyklėms. Jei reikia, esamus galite pakeisti skirtingais įrankiais; Ir verslo taisyklės nesikeis. Na, taip, bet jį reikėjo perkoduoti, nes šie įrankiai buvo naudojami originalioje duomenų bazėje. Tai tavo problema. Ką turi galvoje? Jūsų problema ta, kad manote, kad verslo taisyklės priklauso nuo duomenų bazės įrankių, bet taip nėra. Arba bent jau taip neturėtų būti, kol nebus sukurta gera architektūra. Tai tiesiog beprotiška. Kaip sukurti verslo taisykles, kurios nenaudoja šių įrankių? Nesakau, kad jie nenaudoja duomenų bazės įrankių, bet nuo to nepriklauso. Verslo taisyklės neprivalo žinoti, kurią duomenų bazę naudojate. Taigi, kaip gauti verslo taisykles nežinant, kokius įrankius naudoti? Apverskite priklausomybes, kad duomenų bazė priklausytų nuo verslo taisyklių. Įsitikinkite, kad veiklos taisyklės nepriklauso nuo duomenų bazės. Tu kalbi nesąmones. Priešingai, aš naudoju programinės įrangos architektūros kalbą. Tai yra priklausomybės inversijos principas: žemo lygio standartai turėtų remtis aukšto lygio standartais. Nesąmonė! Aukšto lygio kriterijai (darant prielaidą, kad daroma nuoroda į verslo taisykles) Žemo lygio kriterijų iškvietimas (darant prielaidą, kad tai susiję su duomenų bazėmis). Todėl aukšto lygio kriterijus bus grindžiamas žemo lygio kriterijumi pagal principą, kad skambinantysis priklauso nuo skambinančiojo. Visi tai žino! Tai tiesa vykdymo metu. Tačiau kompiliuodami norime priklausomybės inversijos. Aukšto lygio gairių šaltinio kode neturėtų būti minimas žemo lygio gairių šaltinio kodas. Nagi! Kaip galite paskambinti to nepaminėjus? Žinoma, jokių problemų. Štai kas yra orientuota į objektą. Objektinė orientacija yra realaus pasaulio modelio kūrimas, derinant duomenis, funkcionalumą ir darnius objektus. Tai apie kodo sutvarkymą į intuityvią struktūrą. Štai ką jie sako? Kaip visi žinome, tai akivaizdi tiesa. Taip, tačiau naudojant objektines gaires, iš tiesų galima remtis to neminint. Na, kaip tai padaryti? Objektiniame dizaine objektai siunčia pranešimus vienas kitam. Žinoma, teisingai. Kai siuntėjas siunčia žinutę, jis nežino gavėjo tipo. Tai priklauso nuo vartojamos kalbos. "Java" siuntėjas žino bent bazinį imtuvo tipą. Ruby siuntėjas bent jau žino, kad gavėjas gali apdoroti gautus pranešimus. Teisingai. Tačiau bet kokiu atveju siuntėjas nežino konkretaus gavėjo tipo. Teisingai, gerai, taip yra. Todėl siuntėjas gali suprojektuoti imtuvą, kad jis atliktų funkciją, nenurodydamas konkretaus imtuvo tipo. Teisingai, teisingai. Suprantu. Tačiau siuntėjas vis tiek priklauso nuo gavėjo. Tai tiesa vykdymo metu. Tačiau kompiliuojant jis skiriasi. Siuntėjo šaltinio kodas nemini ir nepriklauso nuo gavėjo šaltinio kodo. Tiesą sakant, gavėjo šaltinio kodas priklauso nuo siuntėjo šaltinio kodo. Jokiu būdu! Siuntėjas vis tiek priklauso nuo siunčiamos klasės. Galbūt iš kokio nors šaltinio kodo bus aiškiau. Ši pastraipa parašyta Java. Pirmasis yra siuntėjas: siuntos siuntėjas; viešoji klasė Siuntėjas { privatus Gavėjo imtuvas; viešasis siuntėjas (gavėjas r) { gavėjas = r; } public void doSomething () { receiver.receiveThis (); } viešoji sąsaja Imtuvas { void receiveThis (); } }Štai imtuvas: pakuotės imtuvas; importuoti siuntėją. Siuntėjas; viešoji klasė SpecificReceiver įgyvendina Sender.Receiver { public void receiveThis () { //do something interesting. } }Pastaba: Gavėjas priklauso nuo siuntėjo, SpecificReceiver priklauso nuo siuntėjo, o siuntėje nėra su gavėju susijusios informacijos. Taip, bet jūs meluojate, jūs įdėjote gavėjo sąsają į siuntėjo klasę. Jūs pradedate suprasti. Ką tu žinai? Žinoma, tai yra architektūros principas. Siuntėjas turi sąsają, kurią gavėjas turi įdiegti. Jei tai reiškia, kad turiu naudoti įdėtas klases, tada ...... Įdėtos klasės yra tik viena iš priemonių tikslui pasiekti, yra ir kitų būdų. Na, palaukite. Ką tai turi bendro su duomenų bazėmis? Pradėjome kalbėti apie duomenų bazes. Pažvelkime į kodą šiek tiek daugiau. Pirmoji yra paprasta verslo taisyklė: paketas businessRules; importuoti objektus. Kažkas; viešoji klasė BusinessRule { privatus BusinessRuleGateway šliuzas; public BusinessRule (BusinessRuleGateway gateway) { this.gateway = šliuzas; } public void execute (eilutės id) { gateway.startTransaction (); Kažkas dalykas = gateway.getSomething (id); thing.makeChanges (); gateway.saveSomething (daiktas); gateway.endTransaction (); } }Verslo taisyklės neturi didelio svorio. Tai tik vienas pavyzdys. Gali būti daugiau tokių klasių, kurios įgyvendina daug skirtingų verslo taisyklių. Gerai, tai kas tiksliai yra "Gateway"? Jame pateikiami visi duomenų prieigos būdai pagal verslo taisykles. Įgyvendinkite jį taip: paketas businessRules; importuoti objektus. Kažkas; viešoji sąsaja BusinessRuleGateway { Something getSomething (eilutės ID); anuliuoti startTransaction (); void saveSomething (Kažkas dalykas); void endTransaction (); }Pastaba: tai yra businessRules. Gerai, kas yra "Kažkas" klasė? Tai yra paprastas verslo objektas. Aš įdėjau jį į subjektus. paketo subjektai; viešoji klasė Kažkas { public void makeChanges () { //... } }Galiausiai BusinessRuleGateway įgyvendinimas, ši klasė žino tikrąją duomenų bazę: paketų duomenų bazė; importuoti businessRules.BusinessRuleGateway; importuoti objektus. Kažkas; viešoji klasė MySqlBusinessRuleGateway įgyvendina BusinessRuleGateway { public Something getSomething (String id) { // naudokite MySql gauti daiktą. } public void startTransaction () { // start MySql transaction } public void saveSomething (Something thing) { // save thing in MySql } public void endTransaction () { // end MySQL operacija } }Be to, atkreipkite dėmesį, kad veiklos taisyklės iškviečia duomenų bazę vykdymo metu; Tačiau kompiliavimo metu duomenų bazė apima ir priklauso nuo businessRules. Na, manau, suprantu. Jūs tiesiog naudojate polimorfizmą, kad paslėptumėte faktą, kad duomenų bazė yra įdiegta iš verslo taisyklių. Tačiau sąsaja vis dar reikalinga, kad visi duomenų bazės įrankiai būtų pateikti verslo taisyklėms. Ne, visai ne. Mes nebandėme pateikti duomenų bazės įrankių verslo taisyklėms. Vietoj to, jie naudoja verslo taisykles, kad sukurtų sąsajas tam, ko jiems reikia. Įdiegę šias sąsajas galite iškviesti tinkamus įrankius. Taip, bet jei jums reikia naudoti kiekvieną įrankį visoms verslo taisyklėms, tiesiog įdėkite įrankį į šliuzo sąsają. Nemanau, kad tu vis dar supranti. Suprantate ką? Tai jau aišku. Kiekviena verslo taisyklė apibrėžia tik vieną sąsają reikalingiems duomenų prieigos įrankiams. Palauk, ką tu sakai? Tai yra sąsajos atskyrimo principas. Kiekviena verslo taisyklių klasė naudoja tik tam tikras duomenų bazės priemones. Todėl kiekvienos verslo taisyklės teikiamos sąsajos gali pasiekti tik atitinkamas priemones. Tačiau tai reiškia, kad yra daug sąsajų ir daug mažų diegimo klasių, kurios iškviečia kitas duomenų bazių klases. Puiku, jūs pradedate suprasti. Bet tai per daug netvarkinga ir laiko švaistymas. Kodėl tai daryti? Tai organizuota ir taupo laiką. Nagi, gauk daug kodo dėl kodo. Priešingai, nereikšmingi sprendimai gali būti atidėti svarbiais architektūriniais sprendimais. Ką tai reiškia? Pamenu, pradžioje sakėte, kad norite būti programinės įrangos architektu, ar ne? Norisi priimti visus sprendimus, kurie iš tikrųjų yra svarbūs. Taip, taip maniau. Norite priimti sprendimus dėl duomenų bazių, žiniatinklio serverių ir sistemų, tiesa? Taip, jūs sakote, kad nieko iš to nesvarbu. Tiesiog nereikšmingas turinys. Teisingai. Viskas. Svarbūs programinės įrangos architektų sprendimai yra tie, kurie leidžia priimti sprendimus dėl duomenų bazių, žiniatinklio serverių ir sistemų. Bet jūs turite nuspręsti, kurie iš jų pirmiausia! Ne, tai neveikia. Tiesą sakant, tai gali būti nuspręsta vėliau kūrimo ciklo metu, kai informacija bus gausesnė. Katastrofa, jei architektai iš anksto nustato sistemas, kad tik pamatytų, kad jos neužtikrina reikiamo našumo arba įveda netoleruotinus apribojimus. Tik tada, kai architektas nusprendžia atidėti sprendimą, jis priima sprendimą, kai informacijos pakanka; Komandos, kurios nenaudoja lėtų ir daug išteklių reikalaujančių IO įrenginių ir sistemų, architektų nuožiūra gali sukurti greitą, lengvą testavimo aplinką. Tik jos architektams rūpi tai, kas iš tikrųjų svarbu, ir atideda tuos, kurie to nedaro, o tokiai komandai pasisekė. Nesąmonė, aš visai nesuprantu, ką turite omenyje. Na, gerai pažvelkite į šį straipsnį, kitaip turėsite palaukti dar 10 metų, kad tai išsiaiškintumėte.
| 
Paskelbta 2017-09-27 15:29:46
|
|
|
Paskelbta 2017-09-28 15:00:37
|
Savininkas|
Paskelbta 2017-09-29 08:34:23
|
Paskelbta 2018-11-27 11:12:17
|
