[c#] n-tier & ExecuteReader

[LoekD]

Ik zit met een n-tier dilemma. In de Data-access laag maak ik gebruik van een (SQL) DataReader, om gegevens op te halen voor een Business Object.

Nu moet je (ik) dus een data-access object (de DataReader) moeten gebruiken in de business-laag, om het Business obj te vullen. Bovendien zit ik dan nog met het Connection object (de Connection moet gesloten worden na Reader.Close() ).
In dat geval kan ik niets anders bedenken dan de Connection als 'out' parameter terug te geven en in de business laag te Disposen.

Het klinkt allemaal behoorlijk smerig en onwenselijk.

Iemand een beter idee?

[whoami]

Een datareader zou nooit je DAL uit mogen gaan.

Je kan in je DAL een datareader gebruiken om een custom collection mee op te vullen, en dan laat je je DAL - object / method die custom collectie returnen.

Op die manier wordt je connectie netjes gesloten in je DAL en hoeft je BL niks te weten over datareaders, connecties, etc....

[LoekD]

whoami schreef op 03 mei 2004 @ 11:50:
Een datareader zou nooit je DAL uit mogen gaan.

Je kan in je DAL een datareader gebruiken om een custom collection mee op te vullen, en dan laat je je DAL - object / method die custom collectie returnen.

Op die manier wordt je connectie netjes gesloten in je DAL en hoeft je BL niks te weten over datareaders, connecties, etc....

Een custom collection is een Business object.. dus dat levert behalve een circular dependency ook nog eens een omgekeerd probleem.
Een eenvoudige namevalue collection zou natuurlijk wel een optie zijn. Maar dat strookt niet wanneer je bijv. meer dan 1 kolom aan gegevens ophaalt.

[whoami]

Hmm, een custom collection hoeft imo niet altijd een business object te zijn.
Je kan gewoon een class definieren in je DAL die enkel de gegevens bevat die moeten gereturned worden.
Dan is het eigenlijk net hetzelfde als dat je DAL method een DataTable zou returnen.

[LoekD]

Het komt er dus op neer dat in een net n-tier geen plaats is voor een DataReader, in dit geval.

Feitelijk kun je zo'n DataReader alleen gebruiken om bijv. een recordset op te halen en de gegevens te gebruiken voor verdere Database acties.

In plaats van door zo'n recordset te gaan loopen om zo'n Collection op te bouwen, gewoon lekker een DataTable ophalen... scheelt weer typwerk.

Eens?

[gorgi_19]

LoekD schreef op 03 mei 2004 @ 13:27:

In plaats van door zo'n recordset te gaan loopen om zo'n Collection op te bouwen, gewoon lekker een DataTable ophalen... scheelt weer typwerk.

Eens?

Nope, als je het om het typewerk doet, kijk dan eens naar O/R Mappers.

[EfBe]

LoekD schreef op 03 mei 2004 @ 13:27:
Het komt er dus op neer dat in een net n-tier geen plaats is voor een DataReader, in dit geval.

Feitelijk kun je zo'n DataReader alleen gebruiken om bijv. een recordset op te halen en de gegevens te gebruiken voor verdere Database acties.

In plaats van door zo'n recordset te gaan loopen om zo'n Collection op te bouwen, gewoon lekker een DataTable ophalen... scheelt weer typwerk.

Als het je puur om de data te doen is, kan dat werk schelen inderdaad. Echter, als je met die collection wilt werken is het loopen door een datareader wel efficienter, je hoeft immers geen datatable uit te lezen en om te zetten naar de collection en je slaat overhead over die intern in de dataadapter wordt gebruikt.

Het is wellicht nuttig om eens naar interfaces te kijken. Je definieert dan bv een interface in je DAL voor 'ObjectCollection' en je business object implementeert die interface. Je geeft dan je business object door aan de DAL, die gebruikt de interface om de business object te vullen middels een datareader en geeft dan het object weer terug. Geen cyclic references en generieke code op de koop toe

[LoekD]

Da's inderdaad wel een originele, redelijk nette oplossing. Volgens de standaarden, wil je echter geen data-definities vastleggen in je DAL.

MSDN Zegt op "ms-help://MS.MSDNQTR.2003APR.1033/cpguide/html/cpconwhyadonet.htm"

[..]
Support the N-Tier Programming Model
ADO.NET provides first-class support for the disconnected, n-tier programming environment for which many new applications are written. The concept of working with a disconnected set of data has become a focal point in the programming model. The ADO.NET solution for n-tier programming is the DataSet
[..]

Elders zijn ze weer lyrisch over de DataReader...
ms-help://MS.MSDNQTR.2003APR.1033/dnbda/html/bdadotnetarch031.htm
(dan ga ik er vanuit dat MS uitsluitend het n-tier principe predikt)

[whoami]

Je kan een DataReader perfect in een DAL gebruiken. Echter, de definitie van dat 'generiek' object leg je ook niet vast in je DAL, het enige wat die DAL van dat object weet, is z'n interface.

[LoekD]

gorgi_19 schreef op 03 mei 2004 @ 13:35:
[...]

Nope, als je het om het typewerk doet, kijk dan eens naar O/R Mappers.

[off-topic]

.. als ik het alleen om het typewerk zou doen, zou ik er geen topic over volschrijven..

In ieder geval... da's inderdaad een ontzettend handig concept.

[/off-topic]

[LoekD]

Leuk detail..

In het 'User Interface Process' building block maakt een mannetje van MS zelf een datatable aan de hand van een DataReader in 'SqlHelperExtention.cs'.

Da's een derde optie....

code:

while( dataReader.Read() )
            {
                if( recNumber++ >= from )
                {
                    fillRow = fillTable.NewRow();
                    for( int fieldIdx = 0; fieldIdx < dataReader.FieldCount; fieldIdx++ )
                    {
                        fieldName = dataReader.GetName( fieldIdx );
                        if( fillTable.Columns.IndexOf( fieldName ) == -1 )
                            fillTable.Columns.Add( fieldName, dataReader.GetValue( 
                                  fieldIdx ).GetType() );
                        fillRow[ fieldName ] = dataReader.GetValue( fieldIdx );
                    }
                    fillTable.Rows.Add( fillRow );
                }
                if( count != 0 && totalRecords <= recNumber )
                    break;
            }

edit:

in de Quickstart sample Store Win & Web

[ Voor 6% gewijzigd door LoekD op 04-05-2004 09:14 . Reden: bron toegevoegd ]

[EfBe]

Met de hand een datatable aanmaken mbv een datareader is wel de meest onbenullige tijdsbesteding die ik kan bedenken. Dezelfde routine heb je al beschikbaar, in de DataAdapter. Bevestigd wel mn vooroordeel jegens die building blocks: vaak erbarmelijke kwaliteit.

(Overigens worden die building blocks vaak door externe consultants gemaakt, vandaar ook dat ze veelal totaal verschillende filosofieen gebruiken.)

[ Voor 24% gewijzigd door EfBe op 04-05-2004 09:32 ]

[LoekD]

't Is ook niet de optie die ik zou kiezen nee.. maar 't is een mogelijkheid....

Overigens vraag ik me af hoeveel building blocks je goed hebt bekeken om tot de bovenstaande conclusie te komen?

Persoonlijk ben ik erg te spreken over deze, maar ook het Logging Block vind ik geweldig.

(De code die ik heb geplaatst komt uit het voorbeeld, niet uit het building block zelf.)

[EfBe]

DAAB, Configuration block, exception block. Log4net is wat ik zou kiezen voor logging, simpel, effectief en betrouwbaar. De blocks van MS blinken niet echt uit in een goede opzet van de code, veel is inmens ingewikkeld opgezet maar dat is vaak nergens voor nodig, of ze omvatten erg veel code voor echt helemaal niks (DAAB). Evenals de Patterns en practise site overigens (dit is niet alleen mijn mening, maar de mening van veel mensen die ik spreek). Als je iets van patterns wilt leren is het verstandig om op de J2EE patterns site te kijken van Sun.