[ASP.NET] multi tier database connection

[PhoneTech]

Hallo kijkbuiskinderen,

Ik ben met een <belachelijke MS naam>Solution</belachelijke MS naam> bezig met daarin een aantal projecten namelijk

- BackSite (ASP.NET C# Project) (Site structuur opbouwen, management)
- MidSite (ASP.NET C# Project) (WYSIWYG editors en dat soort shit)
- FrontSite (ASP.NET C# Project) (Het resultaat )

- Components (C# Class Library)
- DataAccess (C# Class Library)

Alle ASP.NET applicaties maken gebruik van dezelfde logica, scheelt echt een hoop werk.

Maar nu komt ie...

Eerst maakte ik altijd een database connectie door in de web.config de volgende code op te nemen:

code:

<appSettings>
<add key="ConnectionString" value="server=localhost;Trusted_Connection=true;database=Bsu" />
</appSettings>

En dan in DataAccess classen gebruikte ik dan

code:

SqlConnection myConnection = new SqlConnection(ConfigurationSettings.AppSettings["connectionString"]);

Maar dat kan nu niet meer omdat ik de database access volledig uit de presentatie lagen wil hebben.

Hoe kan ik in een class library een globale variabele maken waarin ik de connection string zet die dan in elke class beschikbaar is?

Is er een betere manier om de connection string voor de DataAccess library beschikbaar te maken?

[gorgi_19]

Wat is er mis mee om deze in je web.config te zetten? Je kan eventueel ook een soort van apart configuratiebestand maken en deze inlezen als application variabelen. Als je in plaats van ConfigurationSettings.AppSettings["connectionString"] gebruikt maakt van een method / property, dan heb je verder nog als voordeel dat je eerst kan testen of de variabele leeg is.

Zo ja, dan opnieuw inlezen.

Zelf maak ik me er eigenlijk niet druk om; een connectionstring in web.config moet kunnen. Ik beschouw deze eigenlijk meer als een algemene configuratie-instelling van een pakket, waar anderen best aan mogen komen (net als de presentation layer)

[PhoneTech]

Das waar..maar ik wil mijn database akties helemaal los van de presentatie lagen hebben!

Er komen misschein nog standalone windows applicaties die er gebruik van gaan maken en die kunnen dan mindermakkelijk bij de web.config.

Ik heb het al een beetje op zitten lossen door een klasse database te maken in de dataaccess laag waar ik de database conneties maak en deze weer opvraag in de de verschillende klassen in de dataaccess library.

[tijn]

PhoneTechnician schreef op 26 oktober 2002 @ 17:44:

Er komen misschein nog standalone windows applicaties die er gebruik van gaan maken en die kunnen dan mindermakkelijk bij de web.config.

Bij Windows applicaties kun je de connectiestring in de app.config opnemen

Ik heb het al een beetje op zitten lossen door een klasse database te maken in de dataaccess laag waar ik de database conneties maak en deze weer opvraag in de de verschillende klassen in de dataaccess library.

Je hebt de connectiestring toch niet hardgecodeerd in de code hoop ik?

[Verwijderd]

The most common attribute/value pairs used by OLE DB are also represented separately by an individual property, such as DataSource and Database (and, optionally, UserId, and Password). When working with a connection object, you can either set the ConnectionString property as a single string, or you can set individual connection properties. (If your data source requires connection-string values that are not represented by individual properties, then you must set the ConnectionString property.) Alternatively, you can also set the ConnectionString property to the path of a Microsoft Data Link (.udl) file. For more information about data link files, see Data Link API Overview.

Even zoeken op Data Link API Overview in je Visual Studio.Net help en je bent er ...

Enjoy

[PhoneTech]

Verwijderd schreef op 26 oktober 2002 @ 19:27:
[...]

Even zoeken op Data Link API Overview in je Visual Studio.Net help en je bent er ...

Enjoy

Thnx. Ik heb het doorgelezen en dit is wat ik wil. Maar nu komt het...Volgens mij maak ik geen gebruik van het OLEDB connectie,

De manier die ik gebruik om eem connectie mee te maken is

code:

SqlConnection myConnection = new SqlConnection(ConfigurationSettings.AppSettings["connectionString"]);

Nu heb ik het met die Data Link geprobeerd door een text bestand in mijn DataAccess Library te maken met de naam database.udl

en dan

code:

SqlConnection myConnection = new SqlConnection("File Name=database.udl;");

maar dat werkt helaas niet...

[gorgi_19]

[gedachtenspinsel]
1. En door middel van een DSN?
[/gedachtenspinsel]

[Verwijderd]

gorgi_19 schreef op 27 oktober 2002 @ 00:26:
[gedachtenspinsel]
1. En door middel van een DSN?
[/gedachtenspinsel]

Tsssss .... DSN's zijn zo .... pre-.NET

Natuurlijk kan je met DSN's werken, maar daarvoor moet je een speciale tool gebruiken, en da's niet makkelijk te deployen. Zo'n .udl file is eigenlijk een DSN in file format, wat makkelijk te deployen en aan te passen is.

PhoneTechnician schreef op 26 oktober 2002 @ 20:55:
[...]


Thnx. Ik heb het doorgelezen en dit is wat ik wil. Maar nu komt het...Volgens mij maak ik geen gebruik van het OLEDB connectie,

De manier die ik gebruik om eem connectie mee te maken is

code:

SqlConnection myConnection = new SqlConnection(ConfigurationSettings.AppSettings["connectionString"]);

Nu heb ik het met die Data Link geprobeerd door een text bestand in mijn DataAccess Library te maken met de naam database.udl

en dan

code:

SqlConnection myConnection = new SqlConnection("File Name=database.udl;");

maar dat werkt helaas niet...

Ik heb er zelf nog niet mee gewerkt, maar gewoon wat gezocht in de documentatie. Je zult zelf wat moeten expirimenteren om het werkend te krijgen.

Als alternatief heb ik ook wat anders voor je gevonden. .NET applicaties die geen Web Application zijn hebben een andere, op web.config lijkende, methode om configuratie gegevens op te slaan. Zoek maar eens op Introduction to Dynamic Properties in de Visual Studio.NET help. En nee, ook hier heb ik geen ervaring mee, dus debuggen mag je zelf doen.

HTH

[alley]

Ik heb in mijn eigen DataAccessLayer de dataaccesslayer laten zoeken naar DAL.config. Hierin staan middels XML wat zaken in beschreven die de DAL nodig heeft om te kunnen draaien.
Als er een System.Web.HttpContext.Current bestaat, zoek ik in het ApplicationPath van deze Context, anders zoek ik in dezelfde directory als de dll....
De waarden van deze .config zet ik in static variabelen...

[Verwijderd]

Wat is het probleem? Je DAL classes lezen de web.config uit en lezen de connection string, gebruiken die string voor het openen van de connectie. Je moet het JUIST zo doen, want gebruik je je DAL classes in een andere app, dan kun je dat zonder meer doen, want de connection string staat ergens anders.

/me snapt niet wat sommige mensen voor problemen op de hals halen.

ps: voor een solide voorbeeld van DAL code haal je mijn generator op: LLBLGen op http://www.sd.nl/software en bekijk je de gegenereerde code (SQLServer only).

[Verwijderd]

PhoneTechnician schreef op 26 oktober 2002 @ 17:44:
Das waar..maar ik wil mijn database akties helemaal los van de presentatie lagen hebben!

Web.config is je configuratie van de webapplicatie, dus voor ALLE tiers.

Er komen misschein nog standalone windows applicaties die er gebruik van gaan maken en die kunnen dan mindermakkelijk bij de web.config.

Wellicht is het nuttig wat docs te lezen. App.config rings a bell?

Ik heb het al een beetje op zitten lossen door een klasse database te maken in de dataaccess laag waar ik de database conneties maak en deze weer opvraag in de de verschillende klassen in de dataaccess library.

Dit is niet nodig. Het beste is een base class te maken met daarin je logica omtrent connections etc en daar je DAL classes van te laten inheriten, zodat ze meteen voorzien zijn van DB connection code. Web.config en app.config zijn DE manieren voor het configureren van je applicatie. Niet op gaan lossen op de oude k*tmanieren zoals daar zijn:
- registry (traag)
- ini files (never mind)
- hard coded (errr)
- COM+ strings (werkt niet in alle gevallen)

[gorgi_19]

Verwijderd schreef op 27 oktober 2002 @ 02:58:
[...]

Tsssss .... DSN's zijn zo .... pre-.NET

Natuurlijk kan je met DSN's werken, maar daarvoor moet je een speciale tool gebruiken, en da's niet makkelijk te deployen. Zo'n .udl file is eigenlijk een DSN in file format, wat makkelijk te deployen en aan te passen is.

Tsja.. Geen idee; ik hoef normaal alleen maar Web Applicaties te ontwikkelen en dus alleen met web.config te werken... Was ook maar een gedachtenspinsel he..

[PhoneTech]

Ik heb het inmiddels gewoon via de web.config gedaan. Ben er achter gekomen dat dat toch wel de makkelijkste en snelste manier is om gebruik te maken van de connection string.

Ik heb nog een beetje naar die UDL files zitten kijken, en deze kan je alleen gebruiken als je een OLEDB connection aanmaakt. Omdat ik hier een MSSQL 2000 gebruik, kan ik beter de SqlConnection gebruiken omdat deze beter is afgestemd op de MSSQL server.