Jag skulle vilja ha lite för och nackdelar från erfarna arkitekter för/mot flerskiktade jämfört med tvåskiktade applikationsarkitekturer.

Vi ska bygga om en .NET applikation som körs på ca 30 klienter på ett LAN idag. Idag är applikationen flerskiktad och lagren kan beskrivas så här:

Klientlager - Win Forms, .NET Remoting
Applikationslager - IIS, entitetsramverk, ADO.NET
Datalager - SQL Server, Store Procedures

Mycket av logiken ligger i SQL och store procs. KLienten hanterar fel, valideringar, i/o, m m. Det enda som app lagret gör är att skyffla data och exception över remoting.

Vad ser ni för anledning att inte skapa en 2-skiktad lösning där vi skippar app lagret och låter klienten prata Linq2SQL direkt med SQL? Flerskiktat skapar ju bara merjobb när vi gör förändringar.

Jag skulle vilja höra lite olika åsikter om vägval.

/Dino

Jag är ingen expert på området, så lita inte till 100% vad jag skriver nu... ;)

Rent spontant känns det svårare att hantera rättigheter utan applikationslagret, även om det givetvis går i sp:s.

/Johan

En anledning kanske kan vara att det blir lättare att stödja andra typer av klienter i framtiden.

Mobila enheter, pekskärmar, browserbaserade lösningar.

Du skrev inget om hur ni gör tester. Om ni skall enhetstesta så måste ni väl ändå ha något slags app-lager i klienten. Merjobbet med app-lager lär inte försvinna då.
(Eller tänker ni testa logiken via forms?)

Johan:

Ingen fara, det finns nog inget rätt eller fel.

När det gäller authentisering och behörigheter i 2-skiktat så tänkte vi i så fall använda integrerad säkerhet och roller i SQL. Precis som du säger.

Vi har funderat på hur det skulle vara i en flerskiktad, men jag antar att vi då skulle använda WCF och integrerad säkerhet även där. Behörigheterna skulle i så fall kontrolleras i både app lagret och i SQL. Dubbelkoll alltså. Blir mycket dubbel dubbel dubbel när man ska ha app lager ...

Martin:

Flera klienter (webparts i SPS) kan bli aktuellt i framtiden. Om vi kör tvåskiktat så ser jag i så fall att vi gör en integrationslösning mha WCF-tjänster som implementeras mha samma ramverk som vi använder på klienten för att göra anrop till SQL. Den integrationslösningen kommer ha andra krav på sig en den som supporterar app lagret.

Testning görs av det ramverk som ska kommunicera med SQL och vi testar även delarna i SQL. Klienten testas av användare. Det är som du säger att app lagret (ramverket) ligger på klienten, så enhetstester sker av det. Merjobbet är väl snarare att det finns hostade binärer i flera lager och underhållet kräver hänsyn till det. Känns drygt ... vad tycker du?

Många teoretiker anser att all affärslogik skall ligga i applikationslagret/affärslagret.
Det är bra om mycket kan ligga där, så att det hela är samlat på ett ställe.
Men det är en utopi att tro att allt ska ligga där. Exempel: Du har en huvudtabell på 10 milj rader och 1000 användare. En användare är i snitt behörig till 1% av raderna. En smart lösning är nu att ha behörighet till vissa objekt/rader i tabellen i en behörighetstabell (M:M).
Genom JOIN mot denna tabell kan 99% av raderna elimieras i sökningar och man får ett system som presterar bra. Om du i detta läge är fundamentalist och gör behörighetskontrollen i applikationskod (eftersom det är "afffärslogik" och "måste" ligga där enligt viss litteratur) så blir resultatet katastrofal prestanda.

Sen kan man också tänka så här: Hårdkodad affärslogik är inte snyggt.
t.ex. If (Belopp > 100000.00)
I stället bör sådana regler tabellstyras i ett system som ska vara möjligt att konfigurera.
I det fallet kommer man närmare databasen hela tiden och man ser fler och fler anledningar att utnyttja databasens möjligheter att joina mot affärsregler för att upprätthålla reglerna.
Exempel: Som användare vill jag oftast bara se produkter av ProduktKategori 'T' [Anv.FavoritKategori] som kostar mindre än 2000 kr [Anv.MaxBelopp]. Det är bara 0,01% av alla poster i en stor tabell. Uppenbarligen vill man nu elimiera alla andra rader så tidigt som möjligt, dvs i en SP. Ju mer data och belastning, desto mer intressant blir detta synsätt. I ett väl designat system är affärslogik samtidigt data, eftersom man inte vill hårdkoda all affärslogik.

Det finns inget rätt eller fel man måste se från fall till fall vilket som funkar bäst!

Skulle hålla med ovanstående talare i detta ämne.

Mycket beror på! Man bör ta hänsyn till hur pass enkelt det skall vara att konfigurera systemen. Att sätta affärsregler i databasen är bra, speciellt om man skall se till möjligheterna till ett föränderligt system.

T ex. om man har ett grundsystem som man skapat för försäljning. Företag brukar ha olika affärsregler, det kan bli jobbigt om man alltid skall gå igenom hela affärslagret för att göra dessa ändringar, då är det bekvämt att ha det i ex. 1 eller 2 tabeller i en databas.

Sen är flera skit i många fall att föredra. Ex. om man skall övergå från "WinForm" till "WebForm", då behöver man inte uppfinna hjulet igen, utan bara använda de fina DLL:erna till ex.

Inte så mycket ändringar med andra ord.

Fredrik & Ola:

Tack för era svar. Det är sant att det beror på och jag har försökt beskriva vårat scenario. När det kommer till stora datamängder och flera 1000 klienter så sammanfaller det inte med våra krav. Vi har mindre datamängder som hanteras och ca 30 klienter i ett LAN.

Förändringar slår ofta i alla lager, även om det bara är en affärsregel. I de flesta fall har vi märkt att förändringar oftast är nya kolumner eller andra förändringar i datastrukturerna och då måste alla lager ändras.

Underlätta att gå från WinForms till WebForm är en klassisk anledning att köra flerskiktat. Tänket hos oss är väl att man i så fall nyttjar samma assembly som körs i varje klient för data access och affärslogik. Istället för att hosta den på en server för alla klienter så hostar man den direkt på klienten för WinForms och i IIS för WebForms.

Vi kommer nog ändå köra flerskiktat, men tyvärr inte av någon logisk förklaring utan mest pga att alla "vill det" för det "känns bäst så". Så vida inte någon här kan komma upp med en bra anledning att köra 3-skiktat så kommer vi förmodligen att investera stora pengar i underhåll av kod som bara kommer skyffla data mellan lager.