Data access pattern

[Brimo]

Hej!

 

Jag är på jakt efter ett nytt angreppssätt för att hämta data från DB och mappa denna mot ett objekt som sedan returneras. Ofta när den här uppgifen ska utföras tycker jag det är lätt att koden blir rörig och osäker med nästlade statements i flera nivåer. Det jag letar efter är något sätt att strukturera en eller flera klasser som utför den här uppgiften, utan nästlade anrop. Jag tänker mig nämligen att det är bra att separera olika uppgiter från varandra, så att man t.ex. kan unittesta klasserna.

 

Det är alltså fråga om att:

-Öppna en databaskoppling

-Göra två databas anrop som mappas till ett och samma objekt som sedan returneras

-Hålla dessa anrop inom en och samma transaktion

 

Här är pseudokod som visar den typen av kod jag vill komma bort ifrån:

 

public DataTransferObject SomeMethod()
{
   try
   {
       DataTransferObject MyDataTransferObject = new DataTransferObject();

using(SqlConnection)
{
          //Set up query parameters
          //Begin transaction

          using(SqlCommand)
          {
             //Execute SqlCommand
             //Map result to MyDataTransferObject
          }

          using(SqlCommand2)
          {
             //Execute SqlCommand
             //Map result to MyDataTransferObject
          }

          //Commit transaction
}
       return MyDataTransferObject;
   }
   catch
   {
      //Rollback transaction
      //return null;
   }
}

Några tips om hur något pattern som tillåter att ovanstående görs, men på ett strukturerat sätt?

[Anjuna Moon]

Någon speciell anledning till att du vill uppfinna hjulet på nytt? Använd någon vedertagen OR-mappningskomponent istället är mitt råd, ex. NHibernate, gärna med Castles ActiveRecord ovanpå

 

http://community.jboss.org/wiki/NHibernateforNET

http://www.castleproject.org/activerecord/

[Brimo]

Tack för svar! Jag håller med dig om att NHibernate gör precis det som behövs. Använder det i andra projekt och är nöjd med det.

 

Just i det här fallet handlar det om ett system som i grunden inte är objektorienterat, och jag tror inte att datamodellen fungerar särskilt bra ihop med Nhibernate. Så med andra ord är jag ute efter en ännu enklare lösning, och undrade därför lite hur andra brukar lösa såna här saker.

[Anjuna Moon]

Lite snabbt, jag måste rusa strax men kan återkomma i eftermiddag:

Som jag löste det i ett projekt, innan det fanns bra OR-mappare och innan Net var upp i alltför höga versioner, så använde jag mig av Reflection för att bygga upp denna mappning på generiska objekt.

Alla mina klasser som motsvarade en tabell smyckade jag med attribut (ungefär som man gör med dagens mappare) som identifierade klassegenskaperna som ex. PK, Updateable, Addable osv. samt även motsvarande fältnamn i db-tabellen.

Sedan lät jag mina generiska add, delete, select-metoder via reflection scanna objektet efter dessa attribut och på detta sätt bygga upp SP:n som exekverades.

 

När jag kommer tillbaka kan jag rota upp projektet och se om jag kan posta ett exempel.

[Brimo]

Ja, det skulle vara spännande att försöka något liknande. Hur mappar du i så fall relationer mellan objekt? T.ex. en till många eller en till en?

 

Det låter som om det skulle vara enklast att åstadkomma där det finns tabeller som motsvarar objekten. I mitt fall gör det ju inte det, eftersom systemet inte är designat med objekt i åtanke. Börjar tänka att jag kanske får ge upp allt vad patterns heter. Är det inte objektorienterat från början kanske det är dumt att försöka tillämpa objektorienterade tekniker...

 

Kanske får det räcka med någon form av facade-liknande lösning som bara gömmer undan det värsta databasjobbet...

[Anjuna Moon]

Relationerna löste jag också med attribut (ex, ett FK-attribut som pekade ut foreign-objektet och foreign-fältet). Sedan fick föräldraobjektet helt enkelt lagra barnen i en IList<child> eller annan collectiontyp. Well, väldigt förenklat iallafall.Logiken för att sköta integritet var lite jobbigare förr, innan C# fick fler egenskaper från det funktionella paradigment.

 

Kanske lite tankar från mönstret Domain Driven Design kan fungera? Har precis börjat plöja igenom lite böcker i ämnet och det finns intressanta tankar där för att angripa modelleringsjobbet på lite andra sätt än enligt traditionell entity-modell.

 

Hade det varit möjligt hade jag försökt bygga en objektmodell ovanpå det ostrukturerade lagret hade inte det fungerat så hade jag kanske valt att lägga ett API-lager ovanpå, som åtminstone på något sätt kunde ge det lite mer struktur.

 

Svårt dock att göra annat än generalisera utan att analysera det i detalj. Jag kan säga så här mycket, det är just sådana här problemställningar jag älskar med arkitekturfasen i projekt.

[Brimo]

Oj, ja det fanns en hel del intressant att läsa in sig på om Domain Driven Design, ser jag.

 

Ja, det är frestande, som du säger, att försöka kapsla in allt det gamla och lägga på en objektmodell eller liknande. Jag vet fortfarande inte hur det kommer att sluta, men tack för intressanta och bra uppslag. Nu har jag något att fundera vidare utifrån. :-)