[ASP.Net] Hoe het beste om te gaan met je database

[Verwijderd]

Hallo mede tweakers,

Ik zit de laatse week lekker te prutsen in ASP.Net.

Nu willen ze hier de connectie naar de database maar 1x vastleggen in de applicatie.
Toen dacht ik meteen...... ik maak een soort datamodule waarin mijn connectie staat, met eventueel een aantal veel gebruikte queries.
Die datamodule zet je dan in je sessie en ieder ander bestand kan er gebruik van maken (en als ie niet bestaan aanmaken).

Is dit een goede oplossing.

Of lossen jullie het op een andere manier op?

[whoami]

De connectie-string zet je het best in je web.config. (Dit is ook te lezen in de best practices van Microsoft vermoed ik).

In de web.config kan je een sectie 'appSettings' bijmaken:

code:

<appSettings>
  <add key=connstring
           value=hier komt de connectie-string/>
</appSettings>

Die connectiestring kan je dan makkelijk in uw code ophalen door gebruik te maken van het ConfigurationSettings object:

code:

using System.Configuration;

....
string connstr = ConfigurationSettings.AppSettings["connstr"];

Over het hebben van 1 connectie die je overal kunt gebruiken:
Vind ik zo geen goed idee, zeker niet voor web-applicaties. Aangezien je gebruik kunt maken van connection pooling, is het beter om iedere keer een nieuw connectie-object te maken wanneer je het nodig hebt, en van zodra je geen database-connectie meer nodig hebt, die connectie te sluiten.

Zie ook:
Connection pooling for SQL Server data provider (ADO.NET)

Of uit dit artikel:

ADO.NET Connection
You use the ADO.NET Connection object to create a connection between your program and a database engine. You will normally keep this connection open just long enough to retrieve or update data. By quickly opening, then closing a connection, you use server resources for as little time as possible. This helps you develop scalable, fast applications that are resource-friendly. The fewer resources you use, the more users you can support on your applications at one time.

[ Voor 58% gewijzigd door whoami op 31-01-2003 15:02 ]

[ProgrammerX]

whoami schreef op 31 January 2003 @ 14:50:
Over het hebben van 1 connectie die je overal kunt gebruiken:
Vind ik zo geen goed idee, zeker niet voor web-applicaties. Aangezien je gebruik kunt maken van connection pooling, is het beter om iedere keer een nieuw connectie-object te maken wanneer je het nodig hebt, en van zodra je geen database-connectie meer nodig hebt, die connectie te sluiten.

Waarom is dit geen goed idee ? Ik kan namelijk niet zo ff een nadeel bedenken.

[whoami]

ProgrammerX schreef op 31 January 2003 @ 15:01:
[...]


Waarom is dit geen goed idee ? Ik kan namelijk niet zo ff een nadeel bedenken.

Omdat je dan zo kort mogelijk de resources van die server benut. Die resources geef je dus zo snel mogelijk weer vrij. (Zie ook m'n edit).

Zie ook dit topic:
Database connections

Zeker als je een web-applicatie hebt, is het beter om de connectie zo kort mogelijk open te houden.
Als je echter een Windows applicatie hebt, die bv een access databank benaderd die op dezelfde pc staat, en waar er dus geen sprake is van een 'multi-user' omgeving, dan open ik die connectie ook wel 1x en sluit ik ze pas af als het programma afgesloten wordt.

[ Voor 39% gewijzigd door whoami op 31-01-2003 15:06 ]

[ProgrammerX]

whoami schreef op 31 januari 2003 @ 15:02:

[...]


Omdat je dan zo kort mogelijk de resources van die server benut. Die resources geef je dus zo snel mogelijk weer vrij. (Zie ook m'n edit).

Zie ook dit topic:
Database connections

Zeker als je een web-applicatie hebt, is het beter om de connectie zo kort mogelijk open te houden.
Als je echter een Windows applicatie hebt, die bv een access databank benaderd die op dezelfde pc staat, en waar er dus geen sprake is van een 'multi-user' omgeving, dan open ik die connectie ook wel 1x en sluit ik ze pas af als het programma afgesloten wordt.

Hmm, sterk punt Maar daar ben ik zelf nog niet tegen aan gelopen omdat ik voornamelijk (maatwerk) windows applicaties maak voor een groep van maximaal 15 gebruikers.

[Verwijderd]

Dus zoals whoami zegt, zo kort mogelijk je connectie open houden.
Hoe kort is dat ??

connectie maken, data ophalen, connectie sluiten

of

begin van het laden van de pagina connectie openen en op het einde (finalyze) weer sluiten.

het kan namelijk zijn dat ik meerdere keren iets uit een database moet halen

offtopic:
kan niet sneller replien, zat met Novell in de problemen, mijn login deed het ineens niet meer

[ Voor 10% gewijzigd door Verwijderd op 31-01-2003 15:37 ]

[whoami]

Verwijderd schreef op 31 January 2003 @ 15:37:
Dus zoals whoami zegt, zo kort mogelijk je connectie open houden.
Hoe kort is dat ??

connectie maken, data ophalen, connectie sluiten

of

begin van het laden van de pagina connectie openen en op het einde (finalyze) weer sluiten.

het kan namelijk zijn dat ik meerdere keren iets uit een database moet halen

[/offtopic]

Tja, dat hangt er vanaf.
Als je bv. 7 queries na elkaar moet doen, dan moet je niet 7x een nieuwe connectie ofzo openen. Dan kan je wel iedere keer dezelfde connectie gebruiken. Maar vanzodra je niet direct nog db-access nodig hebt, dan sluit je ze gewono.

[Verwijderd]

OK, dus gewoon connectie openen data eruit vissen.
Als je de connectie een tijdje niet gebruikt sluiten.

En als em weer nogdig heb openen (dan wordt ie uit de pool gestart).

En dan heb je je connectiestring in je web.config staan.
Dus in je sessie setten heeft dan ook geen enkel voordeel, alleen nadeel ?

[gorgi_19]

Verwijderd schreef op 31 januari 2003 @ 15:48:
OK, dus gewoon connectie openen data eruit vissen.
Als je de connectie een tijdje niet gebruikt sluiten.

En als em weer nogdig heb openen (dan wordt ie uit de pool gestart).

En dan heb je je connectiestring in je web.config staan.
Dus in je sessie setten heeft dan ook geen enkel voordeel, alleen nadeel ?

Liever niet in een sessie zetten; je hebt de variabele sowieso al in een application scope staan.

Verder is de connectionstring voor iedere gebruiker dezelfde en imo daarom niet geschikt om in een sessie te zetten.

[Verwijderd]

OK bedankt
ik weet weer genoeg !!

[JohanDM]

Zet nooit je Connection object (of een ander object) in een Session of Application variabele.
Je kan eventueel de connectiestring in een Application variabel zetten, maar als hij in web.config staat (waar hij thuishoort) zit hij ook al in het geheugen, dus daar haal je geen voordeel bij.

[whoami]

JohanDM schreef op 31 januari 2003 @ 16:58:
Zet nooit je Connection object (of een ander object) in een Session of Application variabele.

En custom-objects?
Stel nu dat ik bv een class Persoon heb, en dat ik de gegevens van een opgehaalde persoon (ik heb dus een object 'persoon'), ook in een andere pagina zet, waarom mag ik dat dan niet in een sessie-object zetten?

_{Ik ben ook nog niet zo heel lang bezig met WebApps enzo, dus dat wou ik wel ff weten...}

Je kan eventueel de connectiestring in een Application variabel zetten, maar als hij in web.config staat (waar hij thuishoort) zit hij ook al in het geheugen, dus daar haal je geen voordeel bij.

Ik zou zowiezo de connectiestring niet in een applicatie-variable, noch in een sessie-variable zetten.

[gorgi_19]

whoami schreef op 31 januari 2003 @ 18:56:
Ik zou zowiezo de connectiestring niet in een applicatie-variable, noch in een sessie-variable zetten.

Waarom zou je hem niet in een applicatievariabele zetten? (Appsettings Web.config in web.config beschouw ik trouwens ook als application variabele, omdat ze in mijn beleving ongeveer dezelfde werking hebben..)

[whoami]

gorgi_19 schreef op 31 januari 2003 @ 19:00:
[...]

Waarom zou je hem niet in een applicatievariabele zetten? (Appsettings Web.config in web.config beschouw ik trouwens ook als application variabele, omdat ze in mijn beleving ongeveer dezelfde werking hebben..)

Stel dat je die optie 'displayerrors' ofzo aan hebt staan, en je app crasht, dan kan het gebeuren dat de app. variablen naar het scherm worden getoond.... (toch?)

[gorgi_19]

Ik heb het voor elkaar gekregen om mijn applicatie een aantal keer te laten crashen. Bij een echt 'goede' crash kreeg ik een server unavailable error, waarbij er dus helemaal niets meer getoond werd (wat in dit geval dus goed is)

Bij de overige errors kreeg ik hooguit een stukje van de code te zien, waarbij de aanroep naar de variabele (bv. ConfigurationSettings.AppSettings("connstr") te zien kreeg, niet de inhoud van de variabele.

Verder heeft Microsoft het in zijn voorbeeldapplicaties ook op deze manier gedaan. Het lijkt me dat de web.config wel enigszins veilig is, wdb.

[ Voor 10% gewijzigd door gorgi_19 op 31-01-2003 19:46 ]

[whoami]

gorgi_19 schreef op 31 januari 2003 @ 19:46:
Bij de overige errors kreeg ik hooguit een stukje van de code te zien, waarbij de aanroep naar de variabele (bv. ConfigurationSettings.AppSettings("connstr") te zien kreeg, niet de inhoud van de variabele.

Verder heeft Microsoft het in zijn voorbeeldapplicaties ook op deze manier gedaan. Het lijkt me dat de web.config wel enigszins veilig is, wdb.

En zo doe ik het ook.
Connectionstring in web.config en deze dan ophalen.

Maar, waarom is het nu niet zo'n goed idee om objecten in sessie-variablen op te slaan?

[gorgi_19]

whoami schreef op 01 februari 2003 @ 11:15:

[...]


En zo doe ik het ook.
Connectionstring in web.config en deze dan ophalen.

Maar, waarom is het nu niet zo'n goed idee om objecten in sessie-variablen op te slaan?

quote: http://msdn.microsoft.com...dnasdj00/html/asp1100.asp

The fact that the session object stores all data in the memory of the Web server has two ramifications. First, if you're building a highly available application, or an application to serve a large audience, you'd probably plan to deploy on a Web farm. A Web farm uses two or more Web servers to serve the requests of your users. Load balancing techniques in the Web farm generally round-robin incoming requests across available Web servers to evenly spread the load. Unfortunately, a user's session contents exist on only one of the servers in your Web farm. In order for the session object to work correctly, users must always return to the same Web server for the duration of their sessions.

Most of the load balancing solutions on the market allow you to route users to specific servers. Although this allows sessions to work correctly, this isn't as robust as using all available resources. If one server crashes, all the session contents for users routed to the crashed server are lost. If you store important information in session objects, such as shopping cart information, you might consider a more durable store available to all your Web servers, such as a database.

Second, it's important to note that the Web server receives no notification when a user decides to end his session by closing his Web browser. The data stored in a session object for a user reserves server memory not only between the user's requests, but also for a period of time after he's left the site. After a configurable period of inactivity (the default session timeout in IIS is 20 minutes), IIS will finally fire the session_onEnd event and release the session memory reserved for the user's session.

Imagine you have 1,000 unique users during the first 20 minutes after starting your Web application, and another 1,000 unique users during the next 20 minutes. During those second 20 minutes, IIS will have 2,000 active sessions in memory. On a Web site with high traffic, the memory is put to better use by servicing the requests of active users only.

Dit zijn de twee redenen, welke in ieder geval ook geldig waren voor de oude ASP-omgeving.
Vroeger kon ASP's Session object niet omgaan met Web farms. Het huidige object heeft deze beperking niet meer.
Wel is nog steeds de ruimte geldig. Een session heeft standaard een time-out van 20 minuten. De gegevens blijven dus 20 minuten in het geheugen staan, ondanks dat een gebruiker al weg is. Bij veel bezoekers kan dit een nadeel zijn.

[smoove]

zo heb ik het

<appSettings><add key="connection" value="server=127.0.0.1;Trusted_Connection=true;database=mydatabase" />
</appSettings>

[Verwijderd]

Even voor mijn begrip:

We hebben dus de connectiestring (strConn) in de web.config. Die wordt opgehaald door de web UI. Vervolgens moet er data worden opgehaald. Dan geeft de UI de strConn door aan de BusinessLaag en die geeft 'm weer door aan de DataLaag. Die voert vervolgens met de strConn een sql-query of SP uit.

Best omslachtig toch, om door alle lagen de strConn door te geven, of niet?

[whoami]

Verwijderd schreef op 01 February 2003 @ 15:53:
Even voor mijn begrip:

We hebben dus de connectiestring (strConn) in de web.config. Die wordt opgehaald door de web UI. Vervolgens moet er data worden opgehaald. Dan geeft de UI de strConn door aan de BusinessLaag en die geeft 'm weer door aan de DataLaag. Die voert vervolgens met de strConn een sql-query of SP uit.

Best omslachtig toch, om door alle lagen de strConn door te geven, of niet?

Omslachtig wel, maar wel flexibel toch?

[Verwijderd]

Als je veel met databases gaat werken raad ik je aan om Microsoft Application Data Block for .NET te gebruiken : http://msdn.microsoft.com...us/dnbda/html/daab-rm.asp

Source is vrij te downloaden in C# en VB.NET
<msdn mode>
Summary: The Data Access Application Block is a .NET component that contains optimized data access code that will help you call stored procedures and issue SQL text commands against a SQL Server database. It returns SqlDataReader, DataSet, and XmlReader objects. You can use it as a building block in your own .NET application to reduce the amount of custom code you need to create, test, and maintain. The download provides full C# and Visual Basic .NET source code and comprehensive documentation. (15 printed pages)
</msdn mode>

Ook kun je de databaseconnectie in een klasse zetten. Het voordeel hiervan is dat mensen met rechten op de server je connectiestring niet kunnen lezen (als je site bij 3de gehost wordt) en je hoeft als je de applicatie kopieert geen config files aan te passen voor de database connecties.

Een voorbeeld:
DBConn.vb
<code>
Public Class DBConn
Public ReadOnly Property Connstring()
Get
Return "server=IPofNetbiosnaam;uid=login;pwd=wachtwoord;database=database"
End Get
End Property

End Class
</code>

Gebruik:
<code>
Dim myDBConn As New DBConn()
Dim mySqlCommand As New SqlConnection(myDBConn.Connstring)
</code>

[gorgi_19]

Alleen een beetje jammer dat de connectionstring hardcoded is.. Beetje lastig als je de database op een andere server wilt zetten of het pakket wilt distribueren..

[tijn]

Verwijderd schreef op 01 February 2003 @ 15:53:

Best omslachtig toch, om door alle lagen de strConn door te geven, of niet?

Da's best omslachtig (nouja) en gelukkig ook niet nodig. Je kunt gewoon in je Data Access layer de connectionstring uit je web.config gebruiken door de System.Configuration namespace te importeren.

[ Voor 3% gewijzigd door tijn op 01-02-2003 22:48 . Reden: Nederlandsch ]

[tijn]

whoami schreef op 31 January 2003 @ 18:56:
[nohtml]
[...]

En custom-objects?
Stel nu dat ik bv een class Persoon heb, en dat ik de gegevens van een opgehaalde persoon (ik heb dus een object 'persoon'), ook in een andere pagina zet, waarom mag ik dat dan niet in een sessie-object zetten?

_{Ik ben ook nog niet zo heel lang bezig met WebApps enzo, dus dat wou ik wel ff weten...}

Bij ons laatste project hebben we eens gekeken hoe ver je nou kunt gaan met custom objecten in een sessie object en ik kan je vertellen dat dat heeel ver is (geneste lijstjes met in totaal tot 10000 objecten), zeker wanneer je ook nog eens weinig gebruikers hebt.
Voor de zekerheid hebben we ze wel serializable gemaakt voor het geval dat het geheugengebruik een probleem mocht worden, maar daar hebben we tot nu toe nog geen last van gehad. De performance van het geheel is daarnaast ook nog eens belachelijk hoog.

[Verwijderd]

tijn schreef op 01 februari 2003 @ 22:47:
[...]

Da's best omslachtig (nouja) en gelukkig ook niet nodig. Je kunt gewoon in je Data Access layer de connectionstring uit je web.config gebruiken door de System.Configuration namespace te importeren.

Ja, dat is inderdaad ook een optie. Toch zie ik wel een lastig punt, want stel je voor dat je zowel een Web UI als een Win UI hebt... bij die Win UI is er geen Web.config. Dus, kan je op die manier geen connectionstring ophalen.

Daarnaast vind ik het erg slordig dat je DataLaag dingen gaat ophalen vanaf een webserver. Dan geef ik liever de connectionstring door aan de verschillende lagen.

[tijn]

Verwijderd schreef op 02 February 2003 @ 17:58:
[...]
Ja, dat is inderdaad ook een optie. Toch zie ik wel een lastig punt, want stel je voor dat je zowel een Web UI als een Win UI hebt... bij die Win UI is er geen Web.config. Dus, kan je op die manier geen connectionstring ophalen.

Bij een Win UI kun je een app.config gebruiken...

Daarnaast vind ik het erg slordig dat je DataLaag dingen gaat ophalen vanaf een webserver. Dan geef ik liever de connectionstring door aan de verschillende lagen.

De System.Configuration namespace zorgt ervoor dat je bepaalde instellingen makkelijk kunt lezen enzo. Het maakt hierbij weinig uit (qua gebruik dan) of je een web- of een windowsapplicatie hebt. Bij een webapplicatie gaat ie op zoek naar een web.config en bij een windowsapplicatie naar een app.config om de instellingen uit te lezen.
Misschien ligt het iets minder simpel, maar dan moet iemand anders dat maar even uitleggen .

[whoami]

tijn schreef op 01 February 2003 @ 23:01:
[...]

Bij ons laatste project hebben we eens gekeken hoe ver je nou kunt gaan met custom objecten in een sessie object en ik kan je vertellen dat dat heeel ver is (geneste lijstjes met in totaal tot 10000 objecten), zeker wanneer je ook nog eens weinig gebruikers hebt.
Voor de zekerheid hebben we ze wel serializable gemaakt voor het geval dat het geheugengebruik een probleem mocht worden, maar daar hebben we tot nu toe nog geen last van gehad. De performance van het geheel is daarnaast ook nog eens belachelijk hoog.

Ja, maar dat vreet toch resources.
Wat als er een stuk of 50 of zelfs 100 mensen tegelijk gebruik maken van die applicatie?

[tijn]

whoami schreef op 03 February 2003 @ 08:47:
[...]
Ja, maar dat vreet toch resources.
Wat als er een stuk of 50 of zelfs 100 mensen tegelijk gebruik maken van die applicatie?

Dat valt dus best mee met custom objecten, maar je hebt natuurlijk groot gelijk dat het niet de meest schaalbare oplossing is. Mochten er in de toekomst veel gebruikers komen dan is het een kleine moeite om het geheel te serializen tussen de requests en zo weer wat geheugen vrij te geven. Binnen ASP.NET bestaat ook de mogelijkheid om je sessie data in SQL Server op te slaan ipv het geheugen. Eens kijken of dat een beetje lekker gaat werken. Iemand toevallig ervaring hiermee?

[Verwijderd]

tijn schreef op 02 februari 2003 @ 19:41:
[Ja, dat is inderdaad ook een optie. Toch zie ik wel een lastig punt, want stel je voor dat je zowel een Web UI als een Win UI hebt... bij die Win UI is er geen Web.config. Dus, kan je op die manier geen connectionstring ophalen.]

Bij een Win UI kun je een app.config gebruiken...

Misschien ligt het iets minder simpel, maar dan moet iemand anders dat maar even uitleggen .

Tja, als je gebruikersnamen en wachtwoorden wil gaan bijhouden in een .config file, dan moet je dat dus op 2 plaatsen gaan doen; in de web.config en in de app.config. Is niet echt ideaal wat mij betreft.

[Verwijderd]

Nu even een vraagje over die web.config...

waar laat je die eigenlijk in je solution??
Of compiled die die mee?

[Verwijderd]

Verwijderd schreef op 03 februari 2003 @ 11:01:
Nu even een vraagje over die web.config...

waar laat je die eigenlijk in je solution??
Of compiled die die mee?

Die komt in de projectdirectory onder je www-root te staan.

[Verwijderd]

Is die dan niet voor iedereen uit te lezen ?

[Verwijderd]

Verwijderd schreef op 03 February 2003 @ 11:14:
Is die dan niet voor iedereen uit te lezen ?

Jep. Dus moet je de juiste rechten instellen, zodat niet iedereen erbij kan.

[gorgi_19]

Verwijderd schreef op 03 February 2003 @ 11:54:
[...]


Jep. Dus moet je de juiste rechten instellen, zodat niet iedereen erbij kan.

Wat in principe bij de installatie van het .Net framework gedaan wordt.

[whoami]

Verwijderd schreef op 03 februari 2003 @ 11:01:
Nu even een vraagje over die web.config...

waar laat je die eigenlijk in je solution??
Of compiled die die mee?

Die wordt niet meegecompiled, en 't is eigenlijk gewoon een xml bestand. Die web.config wordt iedere keer ingelezen bij het starten van de applicatie.
Je kunt dus wijzigingen in de web.config aanbrengen zonder dat je uw project moet hercompileren.

[tijn]

Verwijderd schreef op 03 February 2003 @ 10:53:
[...]
Tja, als je gebruikersnamen en wachtwoorden wil gaan bijhouden in een .config file, dan moet je dat dus op 2 plaatsen gaan doen; in de web.config en in de app.config. Is niet echt ideaal wat mij betreft.

Mja, maar wellicht wil je voor je Win UI Windows Authentication gebruiken voor je DB en voor je web UI niet. Dan ben je wel weer handiger uit met 2 config files.

[Verwijderd]

Is er eigenlijk een mogelijkheid om een (xml-) bestand bij een datalaag op te slaan?

Als ik een Data Access project maak (is te vinden via Visual Basic Building Blocks) en daar een App.config file aan toevoeg, krijg ik de jammerlijke melding: "Project DataLaag does not allow File 'App.config' ....."
Maar ik heb ook nog niet zo 1, 2, 3 een mogelijkheid gevonden om een file te openen die een bepaalde naam heeft en in dezelfde directory als mijn Datalaag.dll staat.