Hur är det tänkt att man gör treskiktade databaslösningar i .NET

I VB6 så skrev man ju en COM-komponent som skötte läsningen i databasen och sedan
skickade man ett "disconnected recordset" upp till applikationen.
Hur gör man detta i .NET om man inte skall använda webservices?

/Peter

Jag jobbar just nu på en lösning som bygger hårt på typed datasets .. Har ett presentations lager som är själva Web projektet med aspx och code-behind filer .. Man kan ju göra ett Class bibliotek med Web controler till detta oxå .. eller inkludera dom i samma projekt ..

Sedan har jag ett klassbibliotek för business och datalager .. jag skickar sedan typeddatasets mellan lagrerna .. som jag kan göra lite vad jag vill med ..

De typade dataseten ligger i ett eget klass bibliotek som jag kallar för "Business Entites" typ ..

Man gör det på ungefär samma sätt som i VB6. Dvs mha komponenter. Se MS Application Architecture for .NET: Designing Applications and Services:
http://msdn.microsoft.com/library/default.asp?url=/library/en-us/dnbda/html/distapp.asp

Där borde du får den hjälp du behöver.

Hoppas att det är ett bra svar på din fråga.

/Peter

Ta dig en titt på .NET Architecture Center http://msdn.microsoft.com/architecture/ där finns massor att läsa =)

//Andreas

Jag gör så här www.pdc.se/blog/DisplayEntry.aspx?eid=5

/pD
www.pdc.se
www.pdc.se/blog
www.patrik-dahlen.nu

Ska man prompt ha äkta n-tier system är det väl bäst att använda Enterprise Services dvs COM+ komponenter som man anropar. Man kan även använda .NET Remoting (det blir mer komplext, du måste skriva mycket mer kod själv) eller webservices (XML drar ner prestandan något)
MEN det finns inte så stor anledning att göra det längre tycker jag, i de allra flesta fall.
ASP.NET med codebehind och kompilerade assemblies funkar bra som det redan är och ger oss mycket bra prestanda.
Att å andra sidan dela upp systemet i logiska skikt/komponenter, beroende på komplexitet, är alltid smart (men det kan också vara overkill om systemet inte är så komplicerat).
Ola

Fördelen med Enterprise Services är bla att du kan använda distribuerade transaktioner *woho* =) Sen har .NET utvecklarna gjort det möjligt att konfigurera det mesta med vanliga attribut *woho* =)

//Andreas

Rent konkret kan det se ut så att du här:
Ett projekt med UI (webbprojekt i asp.net)
Ett projekt med Affärslogik
Ett projekt med databaslogik. Detta brukar kallas DAL

Sedan har du antingen Datasets eller egna klasser som skickas mellan de olika lagrena. Data transfer objects (DTO eller Business-entities brukar dessa kallas.

Lagrena känner bara till (refererar) lagrena under sig med undantag för dina DTO som alla projekt måste känna till.

Du får en dll för varje lager, vilket motsvarar dina gamla VB-komponenter (ungefär) och kan återanvändas mellan projekt om dom är väl skkrivna. Främst ditt DAL.