[C# /VS.NET] Beste methodiek ontwerp DAL *

[djlinsen]

Na heel veel tijd te hebben besteed aan zoeken en klooien in vs.net heb ik besloten om maar eens een vraag hier in PW los te laten.

Het probleem zit hem in het de aanpak van het bouwen van een gestructureerde 3-tier webapplicatie. ASP.NET website, webservice, database. Op het punt van de webservice en de dataAccess gaat het mis: mogelijkheid 1 die ik heb gevonden is:
http://www.c-sharpcorner....adovsadonetwebservice.asp
wat er op neer komt om voor elke query die je op de database los wil laten een nieuwe connectie maken en een dataset vullen, werkt prima lijkt me, maar daarmee krijg je dus een lange lijst met functies die de webservice aanbied aan de website, niet ideaal lijkt me.
Mogelijkheid 2 is:
http://msdn.microsoft.com...pplicationwalkthrough.asp
en
http://www.webservicereso...irect.aspx?resourceid=169

Deze manier van werken spreekt me erg aan: kort samengevat met behulp van dataAdapters en dataSets vorm je de benodigde queries waarna je de dataSets door de webserves beschikbaar stelt.
Het probleem hier is dat je dus een groot aantal dataAdapters en dataSets krijgt, is dat wel de bedoeling en is dat handig werken?
Een ander probleem is hoe zorg je er voor dat het een en ander nog object georienteerd blijft?
Is het handig om binnen 1 totale applicatie gebruik te gaan maken van meerdere webservices? dus bijvoorbeeld elke asp.net pagina heeft zijn eigen webservice.

Ik hoop dat jullie begrijpen wat ik bedoel, het is niet mijn sterkste kant om probleemstellingen juist te verwoorden, mocht er iets tekort schieten laat het me weten, dan probeer ik het aan te vullen.

[gorgi_19]

Aanpassing gemaakt in de titel

[Verwijderd]

dus eigenlijk komt het erop neer dat je de lagen wilt laten praten met elkaar via een webservice?

edit:

Betere vraag: waarom wil je de asp.net website laten praten via een webservice? Is dat nodig? Je kan nl ook gewoon via assemblies een 3T applicatie maken.

[ Voor 48% gewijzigd door Verwijderd op 23-02-2005 12:23 ]

[whoami]

Heb je je eigenlijk wel afgevraagd of het nodig is in dit geval om gebruik te maken van een webservice ?
Ik zie eigenlijk niet direct het nut in om een webservice te gebruiken als je een asp.net webapplicatie wilt ontwikkelen....

[Verwijderd]

Webservices kun je inderdaad gemakkelijk gebruiken in je applicaties (Win of web). Je kan ook webservice classes afleiden van elkaar zodat je bv. een basis webservice class kan maken met daarin basisfunctionaliteit. Deze functionaliteit houdt in: het openen van een connectie met een databank, het aanmaken van een adapter op basis van een SQL string die je doorgeeft, het vullen van een dataset, enz... Op die manier moet je in de designer geen 10-tallen adapters maken voor elke tabel. Voor updates in de databank kan je gebruik maken van business objecten die via reflectie gebruikt worden om een INSERT, UPDATE of DELETE query uit te voeren. Dit is maar 1 systeem die je kan gebruiken. .NET biedt ongelooflijk veel mogelijkheden om hiermee om te gaan...

[whoami]

Verwijderd schreef op woensdag 23 februari 2005 @ 12:28:
Webservices kun je inderdaad gemakkelijk gebruiken in je applicaties (Win of web). Je kan ook webservice classes afleiden van elkaar zodat je bv. een basis webservice class kan maken met daarin basisfunctionaliteit. Deze functionaliteit houdt in: het openen van een connectie met een databank, het aanmaken van een adapter op basis van een SQL string die je doorgeeft, het vullen van een dataset, enz... Op die manier moet je in de designer geen 10-tallen adapters maken voor elke tabel. Voor updates in de databank kan je gebruik maken van business objecten die via reflectie gebruikt worden om een INSERT, UPDATE of DELETE query uit te voeren. Dit is maar 1 systeem die je kan gebruiken. .NET biedt ongelooflijk veel mogelijkheden om hiermee om te gaan...

Maar dat hoeft niet persé in een webservice. Blijkbaar ben je momenteel niet hip ofzo als je geen webservice gebruikt.
In dit geval is een webservice IMHO totaal onnodig, en zorgt het enkel voor een tragere performance.

[Verwijderd]

Ben het met whoami eens.

De enige reden waarom je je lagen zou willen scheiden met webservices, is als je gaat praten over distributed applications (installaties van de verschillende lagen op verschillende servers) , of als er ook externe applicaties gebruik moeten kunnen maken van jouw functies. Er zijn legio andere manieren (.Net remoting) om je lagen met elkaar te kunnen laten praten zonder web services.

Verder snap ik het statemant niet

Op die manier moet je in de designer geen 10-tallen adapters maken voor elke tabel

je maakt toch 1 functie voor een bepaalde select op die tabel, geeft die aan de datalayer-die vervolgens een DataSet retourneert?

[Maanzaad]

Tenzij je ook andere web (of win) applicaties van je web service gebruik wil laten maken, is het gebruik van een web-service overbodig en vertragend.

Bedenk overigens wel dat als je datasets beschikbaar wil stellen in je web-service, je wel met een .NET clients moet werken. Een goede webservices werkt met messages die XML beschikbaaar stellen. Zo kunnen de Java Boys and Girls er ook nog wat mee.

XML kan dan aan de client kant weer omgesmurft worden naar iets bruikbaars (bv een dataset). Met dat XML bedoel ik niet SOAP, want dat is alleen de verpakking van de XML message.

[djlinsen]

1 Ding is me alvast duidelijk geworden, webservice is dus niet de meeste ideale oplossing. Ik kwam dit tegen opzoek naar een snelle en overzichtelijke manier van het opzetten van een webapplicatie. In het voorbeeld van msdn kan je ook zien dat de code simpel is en het grootste gedeelte van het werk gedaan wordt door klikken en slepen.

Hoe zou ik het een en ander het beste aankunnen pakken zonder gebruik te maken van die webservices? Ik ben genoeg voorbeelden tegen gekomen op internet waarin de DAL in de ASP.net is geintegreerd, vaak zijn de voorbeeldjes echter te klein om er iets nuttigs mee te kunnen of het is 1 grote onoverzichtelijke codebrei die ik juist niet wil hebben. Snel, overzichtelijk en foutloos programeren is belangrijker dan efficient omgaan met de recources.

[gorgi_19]

Een O/R mapper gebruiken

[whoami]

Je kan een assembly maken met daarin je DAL code, en assembly met daarin de 'business-objecten' en in je ASP.NET applicatie kan je beide assemblies gebruiken:

bv:

code:

CustomersCollection c = CustomersDAL.GetCustomers();

CustomersCollection is dan een class die zich in je 'Business Logic assembly' bevindt, CustomeresDAL bevindt zich in je DAL assembly.

[ Voor 4% gewijzigd door whoami op 23-02-2005 13:32 ]

[Verwijderd]

anders check je even een Microsoft Pattern:

Application Architecture for .NET: Designing Applications and Services

staat e.e.a. wel redelijk uitgewerkt

[Maanzaad]

Ik zou je in overweging geven om te kijken hoe groot je webapplicatie is en wat de toekomst is (levensduur, mogelijke latere aanpassingen, uitbreidingen). Als het een beperkte app. is (zeg met een pagina of 3 a 5) met simpele invoer / uitvoer, maak dan gebruik van de RAD mogelijkheden van VS en laat het 3-laags model voor wat het is.

[djlinsen]

@iruoy,De microsoft patterns ben ik nog aan het bestuderen (160pagina's) dus daar heb ik nog wel een paar dagen voor nodig voordat ik dat gelezen heb en wat mee geprogrammeerd heb.

@maanzaad, wat bedoel je precies met de rad mogelijkheden van VS.net? Ik heb wat rond gekeken maar begrijp niet zo goed welke je bedoeld, zou je iets speciefiker kunnen zijn?

@Gorgi_19, Welke liefst gratis!! O/R mapper is de moeite waard om eens nader te bekijken. Intressante materie in iedergeval die me weer genoeg zoek, lees en leer werk heeft opgeleverd.

[Verwijderd]

djlinsen schreef op woensdag 23 februari 2005 @ 20:26:
@iruoy,De microsoft patterns ben ik nog aan het bestuderen (160pagina's) dus daar heb ik nog wel een paar dagen voor nodig voordat ik dat gelezen heb en wat mee geprogrammeerd heb.

Als je maar de richtlijnen ong door hebt

@maanzaad, wat bedoel je precies met de rad mogelijkheden van VS.net? Ik heb wat rond gekeken maar begrijp niet zo goed welke je bedoeld, zou je iets speciefiker kunnen zijn?

RAD=Rapid Application Development, oftewel, geen gedoe met 3Tier, gewoon zo'n standaard componenten van VS.Net erop knallen, je datasource aangeven en gaan met die banaan

[djlinsen]

Verwijderd schreef op donderdag 24 februari 2005 @ 09:05:
RAD=Rapid Application Development, oftewel, geen gedoe met 3Tier, gewoon zo'n standaard componenten van VS.Net erop knallen, je datasource aangeven en gaan met die banaan

Dat is dus juist niet de bedoeling, Ik wil het een en ander gestructureerd houden, niet zozeer omdat het in dit project moet, maar meer om een standaard methode voor mezelf te hebben hoe ik het ook in andere projecten aan ga pakken. Het is voor mij gewoon wat spelen en leren.

[Maanzaad]

Ben even een tijdje off-line geweest, vandaar de late reactie.
RAD is al uit gelegd. Sleuren en Pleuren dus.

Er is niet één standaard methode voor al je projecten. E.e.a. is afhankelijk van het soort project. Ook in RAD kan je netjes programmeren. Hoe geef ik een goede naam aan variabelen. Try en Catch blokken. Altijd eerste uitzonderings tak van de if/then/else. En ook direct invullen! etc. Zie de Style Guides / best practices van bv. MS. Als het project eenvoudig is dan maak je het met een 3-laags model alleen maar onnodig complex. En dus de kans op fouten groter. 3-laags is dan dus eigenlijk niet zo netjes programmeren.

Een nog belangrijker punt is, is dat het de eindgebruiker worst zal zijn of je 3-laags of iets anders gebruikt. Het belangrijkste voor de eindgebruiker is, is dat het werkt (doet wat het moet doen en stabiel), dat het betaalbaar is en dat het optijd af is. Als goede software ontwikkelaar hoor je je daar als eerste op te richten. 3- laags is niet het doel. 3-laags als het nodig is, RAD als het kan.

[alienfruit]

http://www.remobjects.com/page.asp?id={8FB6795F-7777-43B2-A3F4-74A018FAF227}
Kopen en DataAbstract voor .NET beta testen ;p