Var brukar man normal placera sina objekt och dra gräsen mellan presentationslagret (PL) och businesslogic (BL)?
För mig som är ganska ny på området känns det som om det finns en rejält stor gråzon.

Ett exempel som jag ofta står inför angående detta är när jag ska bygga en webbapplikation. På en aspx-sida har jag ett formulär med ett antal listboxar med val och kanske en textbox där man kan ange en söktext. Ett helt vanligt sökformulär med andra ord.

För att "rätt sökning" skall kunna utföras måste jag samla ihop användarens olika urval från formuläret och köra frågan mot databasen. Samla ihop användarens val ur sökformuläret brukar jag göra i BL, här sker även viss validering av tex. sökfält med mera. Resten av valideingen brukar jag välja att köra på klientsidan med tex. JavaScript.
I vissa fall skall en del beräkningar/bearbetningar göra av de data som tas emot innan de presenteras på sidan. Dessa beräkningar/beasrbetningar utförs också i BL.

Är detta rätt tänk, finns det tumregler? Vad jag greppat är ju att varje lager (helst) skall vara oberoende utav varandra. Det låter enkelt i teorin men jag tycker det verkar skitsvårt att få det så till 100%...
Så när applikationen blir färdig är det oftast så att det är BL som drar det stora lasset. Är det så det brukar vara eller tom. bör vara?

Enligt min syn på det hela bör man aldrig bli fundamentalist i den här branschen. Fundamentalister bygger värdelösa system :) Som du skriver, ibland är det högst lämpligt att höja användarupplevelsen genom ett klientscript som gör viss validering, och ger användaren direkt feedback på inmatningen. T.ex. en summa av 5 orderrader - 10% rabatt. I stället för att behöva posta hela sidan och göra all validering/beräkning i BL på servern. (som OOA/D/P puristerna vill ha det). Det blir ju ett mycket bätte system om vi utgår från användarens upplevelse, och det är väl trots allt det som är syftet med vårt jobb? Men ofta kan det vara lämligt att validera i BL OCH i script, eftersom en "scriptkid" ganska lätt kan tafsa på scriptvalidering och få igenom saker där som inte borde få komma in i systemet. Alltså har man regelverket i BL men man har dessutom en del saker i script för att förhöja användarupplevelsen av systemet. Jag anser att det är dumt att ta fram tumregler för hur detta "alltid måste" göras! Man bör anpassa logiken och graden av säkerhet från fall till fall. Om du utvecklar en Internetbank måste du ta vissa saker i beaktande som du inte behöver göra om det är en sajt för att ladda upp semesterbilder på.
Man ska inte heller glömma bort att tid är pengar. Om du gör ett system som är 300% säkrare och bättre än vad kunden behövde och kanske också 300% dyrare, då har du inte lyckats med uppdraget. Man ska ha ribban på rätt höjd i varje projekt.

Hej Björn,

Du har rätt när du pratar om att ett underliggande lager inte skall kännta till överliggande, det är denna löskoppling man helst skall ha om man vill ha en mer skiktad lösning. En annan fördel är att koden oftast blir snyggare och mer strukturerad. Dock kan underliggande lager prata med övre lager men då via events. Detta är typ en tumregel som man helst skall följa till 100% för att slippa relationsproblem, hårdkopplingar ostrukturerad kod m.m.

Ang logik i PL så är det som Ola säger, vist kan viss logik ligga där, men det beror på vad det är.
Valideringar av mjukare variant kan ske där, men det är oxå viktigt att sådana kontroller ligger på serversidan med pga säkerhet m.m.

Ex. om man bara för skriva en siffra mellan 1-5 så kan man i Javascript göra denna koll för att underlätta för användaren. MEN på serverisdan skall man då kolla så värdet inte är över 5 som kommer in. Detta för att det är så lätt att skapa sin egna klient mot din kod och posta felaktig data.

Det är skillnad på Validering av inputs vs Businesslogik. Ett UI skall bara ha visa och skicka data.
Allt annat som bör utföras i underliggande lager. Du plockar datan från UI i sammanställer den i BL du gör nått med den i BL och BL ger tillbaka data till PL som presenterar det.

Det jag tror du har svårt med är att skillja på är vad är business logik.

Mvh Johan

<b>Ex. om man bara för skriva en siffra mellan 1-5 så kan man i Javascript göra denna koll för att underlätta för användaren. MEN på serverisdan skall man då kolla så värdet inte är över 5 som kommer in. Detta för att det är så lätt att skapa sin egna klient mot din kod och posta felaktig data.</b>

Man behöver inte ens skapa en egen klient. Det är lätt att stänga av JavaScript, särskilt i Firefox (något bökigare i IE).

Jag håller med Johan. Något som jag alltid kör som ett mantra är "Separation of Concerns" vilket i princip är: bryr sig det lagret jag är i just nu om de här sakerna.

En klassiker är cache. Där jag brukar ställa frågan, bryr sig presentationslagret hurvida datan är cachad eller inte? I de vanligaste fallen är svaret nej och cach-logik skall således inte ligga i presentationslagret utan på ngn annan lämplig plats, exempelvis repositories.

En viktig punkt för definitioner av lager är också att de är fristående från den klient kod som använder dem ( och då menar jag objektsklienter inte klienter som applikation). Ett lager bör bara få beroenden skickade till sig på ett eller annat sätt, aldrig leta upp dem själv.

Det gör man enklast med Dependecy Injection via parametrar eller konstruktorer.

Tar upp den här tråden igen...(intressanta svar!)
En fråga som jag inte riktigt blir klok på är var man placerar logik som innehåller information om vilka tabellnamn, columner etc en databas innehåller. Kör (nästan) aldrig med typade dataset.

Ofta (i mina webbapplikationer) så returnerar jag en reader till businesslagret och måste använda typ reader.GetAttribute["Namn"] när jag kör igenom reader'n. I detta fall har jag ju direkt "hårdkodat" ett columnnamn i min businessklass. Detta fungerar ju helt ok att göra så, men det känns som om det finns smartare sätt? Vilka?

Oftast känner jag ju till hur datat är lagrat och köra med reader.GetInt32(1). Skall man göra på detta viset måste väl utvecklaren helt enkelt veta hur databasstrukturen ser ut?

Även databaslagret DAL behöver ju i viss mån veta vad tabeller med mera heter i klartext för att kunna köra SQL-frågor.

Det bör ju vara så att namn på tabeller mer mera endast skall finns angett på ett ställe i en trelagers lösning. Men hur och var?

Kanske en korkat fråga det här. Men som sagt, är rätt grön på området. Har läst många bra trådar här på forumet (bla den om O/R mapping) men jag får inte riktigt poletten att trilla ner...ännu.

Tja!

Jag kan först o främst nämna att jag inte utvecklat någon site med DAL, BLL och PL ännu.

Oftast använder jag en class som tarhandom all Databas hantering och då returnerar dessa alltid icke typade dataset/datatabel eller datarow. Mycket av bearbetningen av datan mellan PL och DAL sker i PL(alltså codebehinde filen till aspx) i de fall att det är en större procedur så görs det i en tools klass.

Med andra ord så fattas jag ett BLL helt.

Nästa applikation jag utvecklar kommer att vara baserat på DAL, BLL och PL.

Jag kan tipsa om denna guid som går igenom stegen väldigt bra!
http://www.asp.net/learn/dataaccess/default.aspx?tabid=63

Slutligen så förstår jag inte helt varför man använder sig av readers, jag tycker det känns bättre att använda sig av DATASET, DATATABEL eller DATAROW beronde på datan. Det känns lite som att man wrapar readern och på så vis för det lite lättare att berarbeta datan. Men det är kanske en smaksak helt enkelt.