Hej!

Jag har en del funderingar kring det här med arv, och hur man lämpligen bygger upp sin applikation. Ett exempel:

När det gäller datalagret (databaskommunikation), om man nu väljer att se applikationen som delat i skikt med UI-lager, affärslogik-lager och data-lager, hur bygger man lämpligen det? Rent spontant skulle jag vilja bygga en enda klass som har två metoder, ex Execute-metod som tar emot ett command-objekt som inparameter och en Select-metod som också tar emot ett command-objekt som inparameter. Denna metod instansierar jag sedan från alla klasser i affärslogik-lagret som behöver kommunicera mot databasen.

Att bygga sin applikation på detta sättet rekommenderas inte. Men varför, vilka är nackdelarna med denna approach? Andra väljer att använda kodgeneratorer som bygger klasser för databaskommunikation, eller bygger en egen sådan kodgenerator. Åter andra väljer att använda arv (kan naturligtvis kombineras med andra approacher). Vad skulle fördelen med att använda låt oss säga en abstrakt basklass med metoder för databaskommunikation som sedan ärvs och instansieras från klasser i affärslogiklagret?

mvh
Hubbe

Generellt sett kan man väl säga att inget skikt bör känna till hur funktionaliteten hos ett annat skikt är implementerad. Dataskiktet hanterar gentemot ovanliggande skikt allt som har med datalagringen att göra. Ovanliggande skikt känner således inte till om data lagras i en relationsdatabas, en xml-fil, i ett stordatorregister eller på månen, utan detta är dataskiktets uppgift. En anledning till detta är att man lätt ska kunna byta lagringssätt eller t.ex. utöka sin applikation till att även fungera mot Oracle.

Jag skulle rekommendera att använda hårt specificerade gränssnitt mellan de olika skikten, så att varje uppgift som ska göras i databasen har en egen metod i datalagringsskiktet. Sedan, om man så vill, kan man ju ha ytterligare ett skikt mellan detta och databasen (t.ex. som du beskriver med command-objekt som inparametrar).

/Pelle

men det du beskriver, att "inget skikt bör känna till hur funktionaliteten hos ett annat skikt är implementerad" gäller ju även min idé om att endast ha en enda databaskommunikations-klass, med två metoder (en Execute och en Select)?

Den databasklass du beskriver skulle snarare konsumeras av de genererade datalagerklasserna än affärslagret. Den gömmer inte databasens struktur för de överliggande lagren.

Ta en till på Microsofts Data Access Application Block för en bra implementation av en grundläggande databasklass. (Själv tycker jag den saknar ett par metoder, men det är ju lätt att åtgärda.)
Download: http://www.microsoft.com/downloads/details.aspx?FamilyID=F63D1F0A-9877-4A7B-88EC-0426B48DF275&displaylang=en

Info: http://www.microsoft.com/resources/practices/code.mspx

Hubert Månsson

Så här kan du göra.

UI (visar bara kontroller och anropar ett mellan lager för att poppulera datan samt skicka tillbaka den.)
|
| UI (user interface) eller PL (Presentationlayer) pratar med Application/Service layer
| Som i sin tur har enkla rutiner för att kommunicera med Äffärslagret. BOL (business object layer),
| DL (Domain Layer) dessa lager har många olika namn.
|
- AL (Application Layer) eller SL (Service Layer) Är ett mellan lager för UI och DL, kan kännas rätt onödigt
| i många fall, men här placeras fasader m.m. som gör att anropen från UI inte blir så komplicerade.
| En fasad är typ en klass som använder sig av flera klasser för att göra en enekel sak.
| Ex, OrderService.AddOrder(orderItem) kan nyttja andra saker som rör en orderläggning, ex plocka ut
| Kundnummer och artiklar etc och använda dessa klassers APIer för att se till så en hel order läggs.
|
- DL (Domain Layer) eller BOL (Business object Layer)... Parantes dock and DL, den är lite bredare än
| De gränser BOL har, men det är ett annat kapitel.
| Här i ligger all affärslogik som AL eller UI kan ropa på. Ex Fasadklassen OrderService.AddOrder...
| Nyttjar Order klassen med sina business rutiner för att hantera order, samt dv andra klasser som
| rör en order, kanske sätter upp en faktura, räknar samman belopp, returnerar belopp till PL när order
| lagts ang rabbater m.m....
|
|
- IL (Infrastructure Layer) eller DAL (Data access Layer). Här har du alla hjälpklasser för hela din
Applikation, så som en SQLHelper, ImageGenerator för UI kanske? generella UI kontroller som alla
dina apps nyttjar gemensamt etc...

Alla lager pratar med IL och alla lager pratar ner till närmsta lager eller till lagren under, men underlager pratar aldrig upp förutom via events då är det tillåtet.
Ex kanske du i UI vill fyllka en OrderItem som kan vara en enitet i DL det gör att du går förbi AL för att få tag i denna vilket är helt ok. Vill du öka lagerhanteringen för att enkelt kunna byta ut dem så kan du nyttja interface orientering, alla dina objekt och entiteter har ett interface som du hela tiden använder dig av. Så när du ex hämtar en entitet OrderItem från DL nyttjar du dess interface.
IOrderItem ornderItem = new OrderItem;

På så vis kan du lätt byta till en ny OrderItem om så skulle vara fallet. Rätt sällsynt dock, jag har aldrig
byggt några applikationer där jag vet att jag behövs byta ut hela objket. Men jag tror io m SOA att detta kan komma att bli vanligare i framtiden.

Gällande dina dataobjekt så tror jag du behöver mer än två metoder. Select vad skall den returnera? DataSet eller DataReader? dessa två datakällor har sin begränsningar och bör nyttjas där de passar bäst in. Det är inte alltid effektivast att nyttja dataset i vissa lägen samma gäller DataReader.
Execute? är det en Update eller en Insert? eller både och? Tror det kan vara bra för spårbarheten att Ha två metoder här oxå. Dettta för att andra skall förstå att du gör en Insert vid ett läge och en Update vid ett annat.

Johan Idstam gav ett bra exempel på ett data access pattern du kan använda. Microsoft, har själv använt det i många lägen och tycker den är utmärkt.

Det finns även många böcker inom detta och om du känner att du behöver kolla mer på det så
tycker jag du skall leta upp någon bok inom området. Om du vill ha tips på böcker säg bara till.

Mvh Johan

Ok tack allihopa! Nu fick jag en hel del att tänka på. :-)

mvh
Hubbe