En ole vielä hirveästi perehtynyt LINQ:n käyttöön mutta mielestäni se tasaa tilit aika pitkälle SQL:n kanssa jos ajatellaan hakujen tekemisen helppoutta. Puhdas objektirakenne ilman tietokannan vaatimia ylimääräisiä rakenteita ja kikkailuja on kehittämisen kannalta huomattavasti nopeampi ja joustavampi vaihtoehto. XML-muotoon tallennettu data on helposti luettavissa ja ymmärrettävissä. Nämä ovat tietysti vain omia mielipiteitäni.
Kieltämättä LINQ tekee tuosta XML-vaihtoehdosta entistä houkuttelevamman. Pitää tutkia sitä lisää. Ei tarttis alkaa kantaa väkertämään ja ylläpitämään.
Lähinnä jonkun fiksun ORM:n käyttäminen vois vähentää kannasta
johtuvaa kikkailua, mutta sellainen taas kuulostaa vähän overkilliltä tuon kokoisessa projektissa. Samassa ajassa, kun säätää esmes NHibernaten tohon niin tekis jo XML:n serialisointiin pohjaavan ratkaisun. Tota datan tallennusta vois olla syytä miettiä vielä uudelleen, nyt kun siihen ei ole vielä juuri mitään tehty ja kelkan kääntäminen on vielä helppoa jos XML:ään päädytään.
Tämä tietysti riippuu täsmällisestä toteutustavasta, mutta väitän ettei vaihto tietokannan ja objektirakenteen välillä ole mikään yksinkertainen operaatio.
Ei tuo mikään ylipääsemättömän vaikeakaan operaatio ole. Niin kauan kun "domain"-objekteihin ei tule suuria muutoksia niin päästään suhteellisen helpolla.
Siksi tuo tuntuikin hieman oudolta kun en keksinyt mihin sellaiseen IList ei olisi tässä taipunut mihin IDictionary taipuu. Äkkiseltään kuvittelisin että propertyn Rows tietorakenne on sellainen että järjestyksellä on merkitystä ja IDictionary on sen oletuksen kanssa täysin ristiriidassa.
Kieltämättä toi IDictionary<>-ratkaisu näyttää omituiselta. Sillä ei tosiaan tuossa tapauksessa saavuteta mitään mihin IList<> ei olisi kyennyt. Pitää fiksata toi tänään rumentamasta maisemaa.
Näytä kirjoitukset
