ASP.NET C# The connection is already Open (state=Open).

[Verwijderd]

Iedere keer, als ik een connectie maak naar de db. Moet ik steeds dit schrijven.
try
{

if (Conn.State == ConnectionState.Closed)

Conn.Open();
}
catch (Exception e)
{
Console.WriteLine(e.ToString());
}

Maar omdat nou steeds dit te gaan schrijven lijkt me zonde!
Iemand eerder hier wat voor bedacht?

[OZ-Gump]

Yup, de verbinding sluiten als je hem niet meer gebruikt of een Data Access Layer maken die dit soort dingen netjes voor je afhandelt.

[6K]

^^ eens is, vooral het de tweede optie

[whoami]

Zo dus:

code:

conn.Open();

try
{
   // blaat
}
catch( ... )
{
  // Miep
}
finally
{
   conn.Close();
}

[D4Skunk]

Kies voor optie 2 : al je database access code centraal in 1 class.
Wanneer je dan bv een nieuwe database engine gebruikt, moet je enkel die class gaan aanpassen.

Ten tweede kan je ook de functionaliteit (logging, smart client maken,...) veel makkelijker uitbreiden, gezien al je code op 1 locatie zit.

C#:

public static class DataManager {

public static string connectionstring='".....";

public static DataTable OpenTable(string sql)
{
... open connectie, lees gegevens, sluit connectie
}

public static void SaveTable(string tablename,DataTable dt) 
{
.. open connectie, maak dataadapter,dataadapter.update(dt),close connectie
}

...
}

Vervolgens, bij het aanroepen :

C#:

DataTable customers=DataManager.OpenTable("select * from customers where ...");

Nog beter zou zijn om een singleton te maken van je datamanager class, en dit mbt multithreading etc...

[ Voor 3% gewijzigd door D4Skunk op 07-03-2005 16:55 ]

[whoami]

D4Skunk schreef op maandag 07 maart 2005 @ 15:51:
Nog beter zou zijn om een singleton te maken van je datamanager class, en dit mbt multithreading etc...

Ik zie in jouw voorbeeld dat je alles 'static' gemaakt hebt; ik vraag me dan af wat een singleton in dit geval meer te bieden heeft mbt multi-threading dan jouw voorbeeld-class.

[curry684]

D4Skunk schreef op maandag 07 maart 2005 @ 15:51:
Kies voor optie 2 : al je database access code centraal in 1 class.
Wanneer je dan bv een nieuwe database engine gebruikt, moet je enkel die class gaan aanpassen.

[.... knip....]

Vervolgens, bij het aanroepen :

code:

DataTable customers=DataManager.OpenTable("select * from customers where ...");

Dus om DBMS portable te blijven schrijf je vervolgens alsnog je SQL in de app zelf?

En wat is nu het nut van die DAL in dit voorbeeld?

[D4Skunk]

curry684 schreef op maandag 07 maart 2005 @ 16:16:
[...]

Dus om DBMS portable te blijven schrijf je vervolgens alsnog je SQL in de app zelf?

En wat is nu het nut van die DAL in dit voorbeeld?

Is slechts een voorbeeldje... uit de losse pols geschreven, dus het zou wel eens kunnen dat er hier en daar een hiaat in zit
Normaalgezien moet je ofwel met stored procedures werken, of met een tussenclass die je gegevens mapt naar je business class... Merk op dat je per entiteit één sourcefile hebt, waar enkel de dataaccess in vervat zit.
Hier een vb voor je datamapping class :

C#:

public static class DMCustomers:DMBase {
     public static Customers GetAllCustomers(){
        DataTable dt=DataManager.OpenTable("Select * from customers");
        return MapDataTableToCustomers(dt);
     }
     public static Customers GetActiveCustomers(){
        DataTable dt=DataManager.OpenTable("Select * from customers where....");
        return MapDataTableToCustomers(dt);
     }
     private static Customers MapDataTableToCustomers(DataTable dt) {
        Customers cs=new Customers();
        foreach (DataRow dr in dt.rows) {
            Customers c=new Customer(dr["id"]);
            c.Name=dr["Name"];
            ...
           cs.Add(c);
        }
     }
     ...
}

en in je hoofdprogramma roep je dan een instance van alle customers als volgt op :

C#:

   Customers allCustomers=DMCustomers.GetAllCustomers()

Je kan natuurlijk ook deze aparte laag laten vallen, en ipv op deze manier te werken, werken met stored procedures.

Ik zeg niet dat dit de enige manier is, maar wel dat dit een manier is die wel degelijk in de praktijk zijn nut al heeft bewezen. (bij mij toch althans )

@whoami : mbt tot multithreading : ik heb zelf niet veel ervaring mbt multithreading, maar zo zou je toch om god-weet-welke-reden-dan-ook twee verschillende instances van je class kunnen aanmaken, zodat bv 1 thread constant een statustabel controleert, en de andere het reguliere werk doet, bv berekeningen etc..., en op die manier vermijd je dan dat je berekeningen gestopt worden omdat er ondertussen een controle op een bepaalde status moet gebeuren...

[whoami]

curry684 schreef op maandag 07 maart 2005 @ 16:16:
[...]

Dus om DBMS portable te blijven schrijf je vervolgens alsnog je SQL in de app zelf?

Jah, dat vond ik ook.
Wat je wel kunt doen is zo'n 'helper class' schrijven, en deze dan gebruiken binnen (een echte) DAL.

[D4Skunk]

whoami schreef op maandag 07 maart 2005 @ 17:00:
[...]

Jah, dat vond ik ook.
Wat je wel kunt doen is zo'n 'helper class' schrijven, en deze dan gebruiken binnen (een echte) DAL.

Zoals deze hierboven ?

[whoami]

D4Skunk schreef op maandag 07 maart 2005 @ 16:52:
[...]

@whoami : mbt tot multithreading : ik heb zelf niet veel ervaring mbt multithreading, maar zo zou je toch om god-weet-welke-reden-dan-ook twee verschillende instances van je class kunnen aanmaken,

Maar het is een static class...

zodat bv 1 thread constant een statustabel controleert, en de andere het reguliere werk doet, bv berekeningen etc..., en op die manier vermijd je dan dat je berekeningen gestopt worden omdat er ondertussen een controle op een bepaalde status moet gebeuren...

Euhm, threads lopen ook niet 'tegelijkertijd' hoor. Het lijkt alleen maar zo.

[whoami]

D4Skunk schreef op maandag 07 maart 2005 @ 16:52:
[...]
Je kan natuurlijk ook deze aparte laag laten vallen, en ipv op deze manier te werken, werken met stored procedures.

En dan? Dan ga je de namen van je SP's in je app staan hebben.
Zelfs als je werkt met SP's, en je wilt je data-laag gescheiden houden, heb je zo een 'tussenlaag' nodig.

[D4Skunk]

whoami schreef op maandag 07 maart 2005 @ 17:02:
[...]

Maar het is een static class...

Wanneer je een singleton maakt, laat je natuurlijk het keyword 'static' vallen imho.
Ehhrm, het kan toch altijd zijn dat je je model ombouwt naar 'meerdere connecties, static is imho bijna nooit de beste aanpak voor een class.
Bij een singleton heb je controle over de aanmaak van een class instance, bij statics niet...Ook zou je een singleton gemakkelijker kunnen omvormen naar een niet-singleton, zonder al je code moeten aan te passen (veronderstel maar eens dat je nu toch besluit om connecties naar verschillende db's tegelijk te maken, wanneer je het singleton pattern gebruikt hebt, moet je dan nergens je code gaan aanpassen, behalve in DataManager.cs zelf)

[...]

Euhm, threads lopen ook niet 'tegelijkertijd' hoor. Het lijkt alleen maar zo.

idd maar database queries lopen imho wel asynchroon, dus als jij je connectie-object gelocked hebt omdat een berekening een update aan het uitvoeren is vanuit de ene thread, kan ondertussen de andere thread wel degelijk zijn query niet lanceren omdat het connectie-object al gelocked is, terwijl de db dit wel perfect aankan. (denk bv aan data die over verschillende servers gespreid is)

[D4Skunk]

whoami schreef op maandag 07 maart 2005 @ 17:04:
[...]

En dan? Dan ga je de namen van je SP's in je app staan hebben.
Zelfs als je werkt met SP's, en je wilt je data-laag gescheiden houden, heb je zo een 'tussenlaag' nodig.

Je moet toch ERGENS een link hebben naar je database ? In het voorbeeld hierboven is die perfect gescheiden...

offtopic:
Ik vind dit een zeer interessante discussie, maar denk dat ze voor de TS al lang niet interessant meer is...
Misschien kunnen we deze discussie via MSN ([e-mail]) of email ([e-mail]) voortzetten ?

trouwens, nog een idiotie in de code die ik vermeld had :

C#:

private static Customers MapDataTableToCustomers(DataTable dt) { 
        Customers cs=new Customers(); 
        foreach (DataRow dr in dt.rows) { 
            Customers c=new Customer(dr["id"]); 
            c.Name=dr["Name"]; 
            ... 
           cs.Add(c); 
        } 
     } 

Moet natuurlijk zijn :

C#:

private static Customers MapDataTableToCustomers(DataTable dt) { 
        Customers cs=new Customers(); 
        foreach (DataRow dr in dt.rows) { 
           cs.Add(MapDataRowToCustomer(dr)); 
        } 

private static Customer MapDataRowToCustomer(DataRow dr) { 
            Customers c=new Customer(dr["id"]); 
            c.Name=dr["Name"]; 
            ... 
}
     } 

[ Voor 40% gewijzigd door D4Skunk op 07-03-2005 17:31 ]

[whoami]

D4Skunk schreef op maandag 07 maart 2005 @ 17:27:
[...]


Je moet toch ERGENS een link hebben naar je database ? In het voorbeeld hierboven is die perfect gescheiden...

Dat zeg ik niet; ik zeg gewoon dat je die SP-namen ook niet zo in je applicatie moet gooien, maar dat je in dat geval ook een gebruik moet maken van die DAL-laag zoals je ze gebruikt in het geval van 'dynamic' queries; alleen ga je dan in die classes geen SQL - queries hebben, maar de namen van je SP's.

offtopic:
Ik vind dit een zeer interessante discussie, maar denk dat ze voor de TS al lang niet interessant meer is...
Misschien kunnen we deze discussie via MSN ([e-mail]) of email ([e-mail]) voortzetten ?

Ik denk niet dat dat zo handig is; op die manier sluit je anderen nl. uit, en trouwens; mijn bak gaat binnenkort uit.