Databashantering

Data-access lagret behöver inte validera input.
Presentationslagret ska göra det.
Har du sedan ett kreditkort, dvs validering av affärstyp så sköter affärslagret den valideringen, då du kanske då måste koppla till en webservice som sköter valideringen.

Data-access lagret behöver inte validera input.
Presentationslagret ska göra det.

Det beror på. Om det är ett dataaccesslager som tar emot en icke parametiriserad sqlfråga så hade jag lagt en validering i mitt dataaccess-lager för att kontrollera så att inga farliga tecken slinker med, det är onödigt att sådan validering skall ligga i varje presentationslager, och innebär en säkerhetsrisk ifall du glömmer den kontrollen i ett presentationslager.

- M

Låt säga att jag använder mig av en mySQL-databas. Ska mina sql-queries ligga i BLL då eller ännu hellre i ett Data Access Logic Layer. Vem bör vara ansvarig för anropen till metoderna i DAL om att ansluta/bryta kopplingen till databasen? Det känns som det borde vara BLL.

Det här funderar jag på (inte nödväntigvis asp.NET)...
BDL:
1. BLL anopar en metod i DAL som ansluter mot databasen -> DAL
2. BLL anropar en metod i DALL som retunerar en SQL-query
3. BLL anropar en metod i DAL och skickar med SQL-queryn som parameter. DAL ansvarar för att exekvera SQL-frågan.

Om jag gjort mig förstådd är jag då rätt ute? Jag anser att det är bättre att inte ha SQL frågorna i BLL, kan nog spara en hel del jobb om jag skulle byta till en annan databas.

Jag hade precis en tråd uppe i ASP.Net forumet om exakt din fråga nu.
http://www.webforum.nu/showthread.php?t=137218
Där har de svarat på din fråga, dvs. min f.d..
Men annars - alltid 1, men BL vet inte om att DAL ansluter. 3, då har du inte fullständig separation (Då behöver du typ en O/R mapper mellan BL och DAL), men det var ändå det som jag gick på i slutet.
2 - nej.

Tack för svaret, intressant läsning, ska plöja igenom de länkarna du postade i den andra tråden. Man kan alltid läsa mer ;)

Jag tycker dock att min tanke som jag klurat på skulle kunna fungera. Ska försöka förklara lite hur jag tänker..

Min tanke är att skapa ett interface, exempelvis UserQueries som deklarerar metoder för sql queries mot en tabelll i databasen som heter User.
Interface skulle kunna se ut så här:

GetAllUsers();
GetUser(int userID);

Låt oss säga att jag tänker använda en mySQL databas. Jag gör då en klass som heter MySQL_UserQueries och denna klass implementerar interface UserQueries. Metoderna innehåller SQL-queries som fungerar med en mySQL databas. Metoderna i denna klass är ganska simpla, de retunerar i princip bara sql-frågorna till BLL.

I min BLL klass UserBLL kan jag då helt enkelt bestäma vilken typ av operationer som ska göras för att hämta data. Detta definierar jag enligt följande:

UserQueries queries = new MySQL_UserQueries();

Då får jag en sql fråga som jag sedan kan köra genom att anropa en metod i DAL, exempelvis execute...

Istället för att skriva in sql-koden direkt i mitt BLL så hämtar jag den på följande vis:

queries.GetAllUsers();

Vill jag sedan byta ut min mysql databas till en access-databas så gör jag bara en ny klass som implementerar interfacet UserQueries. Den enda ändringen jag behöver göra i min BLL klass är följande:

UserQueries queries = new Access_UserQueries();

Det är enkelt att byta tillbaka mellan olika databaser... Istället för att gå in i varje metod och ändra koden.

Hoppas ni förstår vad jag menar? Tycker själv denna lösning verkar okej men det finns säkert någon nackdel? Intresserad att höra vad ni tycker.

Hej,

Vad roligt att du tilltalar mig med "ni" ;)

I alla fall - om du gör så så måste du ju gå in i ditt BLL och ändra varje gång du byter databas. Det är ju emot principen om att de ska vara separerade - jag tänkte så i mina exempel att om du byter databas så kommer i alla fall de mest fundamentala sql-frågorna vara samma - så man borde då kunna behålla BLL intakt utan ändringar.

Du skriver "Metoderna i denna klass är ganska simpla, de retunerar i princip bara sql-frågorna till BLL." Varför skulle du vilja returnera SQL-frågorna (=strängen med SQL-frågan)? Menar du inte att du exposar -- eller hur man nu säger, MySQL_UserQueries publika metoder för affärslagret?

Hur som helst så blir ju nackdelen med det ovan skrivna att du måste ändra i ditt BBL om du byter databas.

Ja det är sant det du säger ;) Tycker i och för sig att ändringarna blir mycket enklare med min metod. Att endast byta ut vilken implemtation av interfacet man skall använda, det kan man nog även välja under runtime.

Ett scenario; låt oss säga att du skriver BDL klass där sql-frågorna skiljer säg avsevärt mellan olika DBMS. Först har du kämpat fär att få det att fungera med Access, sedan bestämmer någon annan att du ska ändra SQL-frågorna till att stödja mySQL. Du sliter och får tillslut ihop det. Efter några månader ändrar sig förutsättningarna ytterligare en gång, nu ska du ha mySQL igen. Då ser jag två alternativ:

1. Du var smart nog att spara de gamla sql-frågorna. Du kör copy & paste och uppdaterar på så vis klassen. Visst det går snabbt men du måste ännu en gång testa varje din BDL klass så att den verkligen gör det ska göra.
2. Du var dum nog att inte spara dina sql-frågor. Du får skriva om dessa igen ;)

Är det inte då enklare att byta ut en deklaration för vilken implementation av interfacet man ska använda istället för att byta ut alla SQL-satser? Min idé är naturligtvis inte felfri, långt ifrån men det finns säkert(?) någon liknande lösning för att göra detta på ett smidigt sätt? Jag är medveten om att min tänkta klass verkligen exponerar sitt innehåll men...

Intressant detta ämnet.

Jag satt själv och funderade lite på olika lösningar häromdagen inom detta område, och jag antar att man kanske skall tänka på vad man har för kvalitetskrav på applikationen man skall göra. Är det viktigt att det skall gå att byta DBMS? Om ja vad behövs för att göra det så smidigt som möjligt att byta databas? Skall man bygga in stöd för flera databaser direkt så man kanske skall ha en variabel som på något sätt skickas med som säger vad det är för SQL query som skall användas? Men detta kanske är lite att arbeta i onödan.

Compusa's lösning fungerar och kanske är den mest optimala. Men man binder upp väldigt många beroenden till just denna klass är det snyggt rent designmässigt?

echoSwe's lösning är snyggare och separerar lite mer, men kanske är lite jobbigare att underhålla när det handlar om flera objekt som man måste gå in och ändra i istället för en om SQL kommandona inte passar för databasen.

Så jag vet inte vilken som är det bästa valet?

Jag har själv två frågor inom detta ämnet.

Säg att vi har nästlande objekt.

t.ex. det finns en produkt och denna produkten har en tabell med en lista av attribut.
Hur skall man på smartast sätt göra produkt objektet?

Skall man samtidigt som man skapar objektet också ta ut alla attributdata och skapa attributobjekt och lägga dessa i en lista i produktobjektet.

Eller skall man kanske bara göra en lista med referenser till datan och sedan skapa objekten när dom behövs.

Eller låta logiken i programmet lista ut att dom är beroende?
Kan det vara skillnad när det gäller Webb eller Win applikation?

Är det verkligen i BL man skall lägga dom klasser som skapar affärsobjekten? Eller har jag missat något?