Modernne tarkvara loomine IV: Andmete kühveldamine

Pea iga rakendus vajab andmete salvestamist, eriti nö andmepõhised rakendused. Seetõttu tuleb meil siduda rakendused andmebaasiga ning võimalusi selleks on mitmeid.

Küllaltki tüüpiline on alguses kasutada andmebaasi lähedast mudelit. Ehitada ise andmete vahetuskiht ja teha DataAccess objekte. Sellise lähenemisega kaasneb hulgaliselt andmekihi kirjutamist, tihti on see lausa 80% projekti mahust ning pärast kolmandat korda tundub, et pidevalt on loodud sama koodi. Oren Eini (Ayende Rahien) ühes ettekandeski ütles, et see on lahendatud probleem ning sellele vastu vaielda väga mõistlik pole.

Mõnigi ettevõtte on otsustanud mingi ajahetk, et tuleb luua enda raamistik andmete vahetamiseks ning kulutanud selle arendamiseks palju aega. Tõesti on tore, kui on võim raamistiku üle, kuid kas see siiski tasub ära? Tuletades enda töökäigu algust meelde, siis tõesti sai paar rakendust tehtud nii, et andmekiht sai ehitatud ise. Pärast Java Persistence API ja NHibernateiga tutvumist ei näinud enam põhjusi tagasiminekuks. NHibernate-i kasutatakse .NET maastikul päris palju ning tehniline tugi on küllaltki suur – kirjuta ainult enda probleem Googlesse ja vastus ei ole kauge tulema.

NHibernate on Object Relational Mapper (ORM), mille ülesandeks on siduda andmebaas objektmudeliga. Selle tulemusena saame peamiselt tegeleda objektidega ja see tundub täiesti mõistlik lähenemine. NHibernate on algselt ületoodud java poolsest raamistikust Hibernate, mis tundub olevat sealsel maastikul vägagi populaarne; PHP-s olen kokku puutunud Doctrine ja Propeli nimelise raamistikuga; .NET maailmas on võimalik kasutada ka Microsofti enda toodangut Entity Framework, mille esimene versioon sai kommuuni poolt tugeva kriitika, kuid vaadates tema tulevikku, siis tundub see paranevat ja võib olla on ka alternatiiviks tulevaste projektide puhul.

Peamiselt kasutatakse ORM-e rikkaliku objektmudeli puhul ning paljud veebirakendused on väga lihtsa ülesehitusega, millest tulenevalt on see veidi ülepaisutatud (siiski kasutaksin pigem ORM-i, kui hakkaksin ise tegelema andmebaasi kihi loomisega). Lihtsamate mudelite puhul on alternatiiviks Active Record muster, kus äriobjekt sisaldab ka päringuid ja salvestamist, kustutamist. Selle mustri headeks näideteks on Ruby on Railsi ActiveRecord ja ka NHibernate-i peale loodud Castle ActiveRecord ning ka SubSonic.

Raamistik, mille osas ma head seisukohta ei oska võtta on LINQ to SQL, mis XML kaardistamise puhul on päris kasutatav. Natukene oli probleeme POCO saavutamiseks, kuid see ei olnud väga valus.

Väikeseks vahepalaks küsiks neilt, kes on oma ettevõttes loonud mõne sarnase asja või arendanud mõnda andmekihi raamistikku, miks need väljapakutud variandi ei ole sobilikud? Olen kuulnud, et üks pühjus on see, et genereeritud SQL päringud ei ole väga head, kuid arvesse võttes keskmise arendaja tugevust selles, siis panustaksin ikkagi siinpuhul esimesele poolele. Teine põhjus võiks olla kiiruse probleemid, kuid see on lahendatav riistvara juurde ostmisega, sest arendajad on kallimad kui riistvara ning pole ka mingisugust garantiid, et tulevane raamistik kiire on. Kolmandaks põhjuseks võiks tuua, et XML on paha, kuid Ruby on Railsi ActiveRecord minu teadmist mööda ei kasutagi mingit seadistust ja NHibernate’i puhul saab kasutada FluentNHibernate’i, mis suures osas võib seadistuse automaatselt ära teha.

Ise olen Oren Einiga nõus, et see on lahendatud probleem. Võime küll luua alternatiivseid lähenemisnurki, kuid ilma suurema põhjuseta ei pole küll mõistlik oma andmekihi raamistikku looma hakata. Võite vürtsitada seda postitust kirjutades kommentaaridesse enda sõjasaagasid.