[C# / Ado / Csla] SqlConnection...

[Verwijderd]

ik gebruik voor mijn .net applicaties het Csla framework. hier een code snippet:

code:

        protected override void DataPortal_Insert()
        {
            using (SqlConnection cn = new SqlConnection(Database.telashopConnection))
            {
                cn.Open();

                ExecuteInsert(cn);

                //update child object(s)
                UpdateChildren(cn);
            }//using

        }

Elke keer dat Save() op een bussines object wordt aangeroepen, wordt deze functie gebruikt.

Nu zit ik met een use-case waar redelijk veel objecten bewerkt en opgeslagen moeten worden.

Is het kwalijk dat elke keer een connectie wordt geopen mbv. new SqlConnection() / cn.Open() en moet ik dit vervangen door bijv. een singleton die de verbinding bevat en eventueel open houdt? of maakt dit weinig uit?

[gorgi_19]

Je gebruikt als het goed is automagisch al een connectionpool

[ Voor 14% gewijzigd door gorgi_19 op 05-07-2007 00:16 ]

[Verwijderd]

dat klopt, dus of je nou 10 of 1000x deze code uitvoert, maakt niet uit?

[Verwijderd]

Voor wat betreft het openen van een connectie maakt dat niet uit. Zolang de connectionstring gelijk blijft, wordt er een beschikbare verbinding uit de pool getrokken.

[whoami]

Dat is -imho- een beetje hèt nadeel van CSLA: connection & transaction management gebeuren in je business objecten zelf.
Zo is het bv niet direct mogelijk om 2 objecten van hetzelfde type bv in één transactie te saven.

[EfBe]

whoami schreef op donderdag 05 juli 2007 @ 09:50:
Dat is -imho- een beetje hèt nadeel van CSLA: connection & transaction management gebeuren in je business objecten zelf.
Zo is het bv niet direct mogelijk om 2 objecten van hetzelfde type bv in één transactie te saven.

Niet? Hmm.. Nooit geweten. Wel raar, dat Rocky dat niet heeft ingebouwd, een transaction manager die de transaction object doorgeeft aan participerende objects is nou niet echt veel werk (lees: paar regels code)

[whoami]

Nou, het is al een tijd dat ik er naar gekeken heb, maar dat was toch één van m'n bezwaren tegen het CSLA framework.
Het kan natuurlijk zijn dat dit in latere versies volledig herzien is.

Voor zover ik me herinner, had ieder BusinessObject in dat framework een 'Save' class, en werd er binnen die 'Save' een connectie geopend en een transactie gestart. Alles wat tot dit object behoorde, werd binnen dezelfde transactie gesaved.
Bv:

code:

Persoon p = new Persoon();
p.SetAdres ( new Adres(...));
p.Save();

De persoon & adres instance werden hier wel in eenzelfde transactie weggeschreven, maar stel dat je 2 personen in eenzelfde transactie wou saven, dan ging dit niet zomaar.

[Niemand_Anders]

Als je zeker wilt zijn dat pooling wordt gebruikt kun je aan de connectionstring ';pooling=true' toevoegen.

Het ontbreken van database transacties (en dan met name de rollback mogelijkheid) in business layers is een kwalijke zaak. Want dat betekend effectief dat je wel fouten met catch kunt afvangen, maar dat je niets ongedaan kunt maken. Bij de meeste frameworks worden de connectie en transactie objecten doorgegeven (ipv van een connectionstring) zodat elk van de business objecten een Rollback() kan geven. Stel dat de schrijfruimte opraakt en je hebt voor een order net de voorraad afgeboekt, dan wordt dat dus niet meer ongedaan gemaakt en kloppen de voorraden niet meer..

[whoami]

Niemand_Anders schreef op donderdag 05 juli 2007 @ 11:41:
Als je zeker wilt zijn dat pooling wordt gebruikt kun je aan de connectionstring ';pooling=true' toevoegen.

Dan nog ben je niet zeker dat connection pooling effictief / efficient gebruikt wordt.

Het ontbreken van database transacties (en dan met name de rollback mogelijkheid) in business layers is een kwalijke zaak. Want dat betekend effectief dat je wel fouten met catch kunt afvangen, maar dat je niets ongedaan kunt maken. Bij de meeste frameworks worden de connectie en transactie objecten doorgegeven (ipv van een connectionstring) zodat elk van de business objecten een Rollback() kan geven. Stel dat de schrijfruimte opraakt en je hebt voor een order net de voorraad afgeboekt, dan wordt dat dus niet meer ongedaan gemaakt en kloppen de voorraden niet meer..

Transaction handling moet buiten de business - objecten zelf gebeuren, want die kennen de context van de use-case niet.
IMHO is dit de beste manier:

code:

start-transactie();
try
{
  customerRepository.Save (some-customer);
  customerRepository.Save (another-customer);
  commit-transactie();
}
catch
{
   rollback-transactie();
}

[Verwijderd]

wat betreft de transacties,
Ik zat even over het forum van rocky te bladeren, en dit is gewoon mogelijk...