Hej!

I ett windows-projekt (eller web för den delen också) som hanterar t.ex. Ekonomi, kunder och hantering av dessa, vilket av dessa två tillvägagångsätt skulle ni då ha valt?

1. Formulär med bundna kontroller och dataset/dataadaptrar. Validering och uppdateringar ifrån formulären och/eller stödklasser. Tyngre beräkningar och annan data-aktivitét i stored procedures i SQL-servern.

2. Fler-lager-lösning med egenskrivna objekt-klasser, t.ex. kund-objekt. Update och delete-frågor sker inne i objekten och viss validering sker i formulären men det mesta i klasserna. Klasserna är avskärmade från formulären.

Fråga om tycke och smak? Är det kanske projektets storlek som avgör? Eller är ett av alternativen alltid rätt?

Mvh
Peter

Hej Peter!

här är min vy på denna fråga.... (om jag bara kunde leva som jag lär.. :)

En fördel med en så kallad n-tier lösning är att man håller
presentations-lagret ( vad klienten ser ) och
business-logiken ( databas accessen mm.) åtskilda, så får man
en mer renodlad kod som är lättare att underhålla och utveckla.
Varje lager gör vad det är bra på och integriteten behålls mellan
lagrena.

t.ex. om man gör en ändring i databasen (data lagret) så behöver
det inte bli så struligt om man har ett separat mellanlager (business-logik)
jämfört med en lösning där presentation och dataaccesslogik är blandad.

dessutom får man kontroll över datan i business lagret om man har den skyddad
i en mellanliggande DLL och kan då exponera olika skräddarsydda metoder för
"presentationskillarna" eller 3rd part. Detta är intill omöjligt om man man låter dom
access:a databasen direkt.

Tjosan Amigo.

Det är inte så enkelt att svara på som det verkar.

Du får utgå ifrån dina behov. Är det extrem prestanda som krävs så finns den en viss prestanda vinst att inte blanda in så många olika lager som man skall gå igenom.

Är man ute efter mer strukturerad kod och underhållningsbara system så är det n-tier lösningar som är lösningen på köpet får du även kod som kan återanvändas i andra lösningar. Det tar lite av prestandan men du lär nog inte märka det, och fördelarna att använda n-tier är så mycket bättre att det blir bättre att köra den lösningen och lägga ner lite mer pengar på en större och bättre maskin om prestandan skulle påverkas (vilket jag inte tror du kommer märka något som helst av).

- M

Hej,

Jag håller i stort med Lars. I det korta perspektivet tror jag dock att alternativ 1 är snabbare. Jag tror inte heller att det behöver vara svårare att underhålla. Tvärt om tror jag att alternativ 2 tillför en "konceptuell komplexitet" som kan göra den mindre "greppbar". Men, om systemet växer eller om man vill återanvända affärslogiken i en annan lösning bör detta bli betydligt enklare om man väljer alternativ 2. Det blir också möjligt att separera logiska "layers" i fysiska "tiers" för ökad säkerhet eller prestanda. Fast, gör man det får man vara beredd på att dela upp affärslogiken i ytterligare lager eftersom denna normalt inte helt kan separeras från presentationslagret (det kanske är en terminologifråga, men jag betraktar input-validering, "skärmflöden" etc som affärslogik). Man kan också tvingas dubblera viss hantering (t.ex. validering - tredubbelt i web-appar).