Flerskiktad kod - affärsskikt,dataskikt

Beror på hur du definerare en assembly. Du kan dock lägga olika dll:er på olika maskiner och få de att jobba ihop som en applikation. Det är dock inget man gör i efterhand i någon wizard, utan kräver att man tänkt in möjligheterna från början, eller bygger wrapper klasser runt din dll efter när allt är färdigt

Jag tror det är viktigt att man håller isär äpplen och päron. Att man lägger DAL .dllen på maskin B och huvudprogrammet på maskin A innebär ju inte att när maskin A exekverar huvudprogrammet kommer DAL .dllen exekvera på maskin B. Men att skapa fristående program som wrappar in databasen via web services där andra program kommunicerar med databasen via detta är ju en annan sak. Personligen tror jag att kommunikation med databasen via web services eller något annat protokoll passar bäst till smart clients lösningar. För om man har en web applikation som kommunicerar med databasen via web services kommer nog innebära en fet latency. För att först måste datan dras ur databasen, sen serieliseras till XML och skickas iväg via HTTP SOAP till web applikationen som i sin tur exekverar och skickar iväg HTML till klienten. Visst kan man cacha sakerna på web servern, men det är inte alla applikationer som har möjlighet att göra detta effektivt, vissa applikationer har ju high insert/update tabeller som måste måste ha "up to date" data hela tiden. Eller vad tror ni om saken?. Diskutera diskutera :)

Att man lägger DAL .dllen på maskin B och huvudprogrammet på maskin A innebär ju inte att när maskin A exekverar huvudprogrammet kommer DAL .dllen exekvera på maskin B.

Inte om den inte efterfrågas, men om man efterfrågar en dll på maskin B från maskin A så kommer denna att exekveras (iallafall om man valt DCOM). Det finna i kråksången (med COM+) är att du programmerar som om DLL:en låg på din maskin, och all kommunikation sker i bakgrunden...

men det är inte alla applikationer som har möjlighet att göra detta effektivt, vissa applikationer har ju high insert/update tabeller som måste måste ha "up to date" data hela tiden. Eller vad tror ni om saken?.

Detta är nog den enda orsak som ger mig anledningen att gå via en webservice för att hämta upp data från databasen. Givetviss beror det på var flaskhalsen ligger, men om flaskhalsen ligger i databasen, så finns det en vinst i att lägga all databaskommunikation via en extern service som kan hålla all information "in memory" och kan kommunicera med databasen efter att svaret redan skickats tillbaka till klienten. Alltså en global cache för databasen. Oftas så finns det ingen vinst i detta då databasen brukar vara rätt så väl tilltagen, men ibland så finns flaskhalsen i databasen, och då kan det vara en ide att skapa en global cache, men om en webservice är kommunikationskanal kan ju diskuteras, det finns bättre och snabbare. .NET remoting hade nog varit mitt första val...

- M

Skulle vara kul om någon orkade slänga upp ett litet exempel på hur en applikation som använder sig av lager skulle kunna vara uppdelad. Skulle vara riktigt intressant. Jag tänker inte direkt på någon kod utan en mer generell beskrivning i form av exempelvis objektdiagram eller liknande.

Du kan ju läsa om hur MS har tänkt sig att det skall vara:

http://msdn.microsoft.com/architecture/application/default.aspx?pull=/library/en-us/dnbda/html/distapp.asp

många intressanta inlägg.. vore bra om någon kunde avsluta denna debatt med en ett bra exempel på kod för att lägga köra en skiktad lösning i visual studio.net... typ lägger jag till ett nytt projekt innehållande dataskikt och affärsskikt? som jag sedan skapar objekt av för att använda mig av... eller hur gör man rent praktiskt om jag skulle vilja testa detta för att lära mig!?

Ett bra svar belönas med "accepteras som slutgiltigt svar" ;-)

Jag skulle göra något i stil med detta, lite annat tjaffs kanske kommer med iof:
1. Spara cnn-sträng i web.config eller något annat smart.
2. Skapa en generell db-wrapper-klass så att du "enkelt" kan växla mellan olika databaser, kallar det för Data Access Layer, DAL
3. Skapa ett Data-Lager, DL, som hanterar sql:er mot DAL.
4. Skapa ett affärslager, BL, som gör anrop mot DL.
5. Presentationslager.

Och ett litet exempel: Säg att en kund i en applikation vill skapa ett konto. Funktionen createAccount(parametrar) anropas i affärslagret. Detta lager anropar funktionerna isUserNameTaken(name) och save(parametrar) från DL eller i BL, beror väl lite på hur man vill göra, så länge man håller isär sakerna så ska det funka. Och sen rinner det bara på, funktionerna i DL kör en sql mot DAL och skickar tillbaka resultatet ...

Ajja, hoppas det klarnar lite, annars är det bara att fråga Gladh, och är det något som är fel så är det hans fel, det var han som "lärde" mig detta i någon tråd för länge sen...

Sen kanske man märker, i alla fall gjorde jag det, att det blir rätt mycket kod som man skriver på nästan samma ställe i olika klasser, så då kan man ju koda ihop något kodgenereringsprogram, t.ex. detta http://member.webforum.nu/1334/CodeGen.JPG (som är något år och till och med i vb.net ussh!) som generar grunden till funktionerna, så slipper man i alla fall att skriva detta.