En liten fråga - ditt DAL-lager ska ju vara databasspecifikt och tanken är att abstraktionen ska vara tillräckligt stor för att du ska kunna byta DAL utan att byta affärslager. Hur gör du då för att utföra komplexa-SQL-frågor som även använder funktioner?
Lägger du det som stored procedures? (stödjs ju av de flesta produktionsdatabaser)
Skriver du din komplexa syntax i ditt DAL som separata funktioner och låter sedan ditt DAL returnera tex. XML, DataSets, DataTable, Structs osv...?
Mitt DAL tar emot en IDBCommand objekt och returnerar ett DataTable. Det betyder att i mitt affärslager så bygger jag upp detta IDBCommand som jag skall använda mig av, och det kan antingen vara för en SP eller för en Parameteriserad SQL fråga och får tillbaka ett DataTable. Sedan skall affärslagret mappa om denna DataTable till de objekt som jag arbetar på.
Eftersom jag är en lat människa så vill jag inte hålla på med denna mappning hela tiden och har istället en O/R Mapper som skapar mina SQL frågor (de flesta) och skickar IDBCommand objektet till mitt DAL och sedan omvandlar DataTablen till objekt.
Sedan, om du har byggt ett community - säg att du vill skicka ett mail till alla som vill bli påminda om att en vän fyller år - var lägger du då SQL-en för denna fråga? I ditt DAL eller i ditt affärslager?
Helt klart i ditt affärslager, ditt DAL är ointresserad vad din SQLfråga skall göra, den skall bara exekvera den och returnera resultatet inte bygga upp den, eftersom denna funktion är specifik för din applikation.
Sedan så funkar det väl så att när man vill använda sina lager, så instansierar man dem genom att referera till dll-filen och sedan skriva:
NameSpace.MittDal objDAL = new MittDal();och låter sedan detta lager returnera tex. en datatable för varje fråga?
Japp!
Sen undrar jag vad som kännetecknar en "collection" - är det helt enkelt en tabell med till exempel redan behandlad data (tex. om en blogg - antal kommentarer, senast lagda kommentar, posten, författare) som är hämtad från de olika tabellerna i databasen?
Collection är en samling av data, så en DataTable är en collection av en massa DataRows, men oftas när man pratar om collections så menar man oftas att den är en samling av "egna objekt". Alltså du har ett objekt som heter Customer, så har man en CustomerCollection som innehåller en samling av Customer.
Kan man på något sätt få med relationerna om man använder ett dataset - alltså utan att sätta dem programmatiskt?
Nu vet jag inte så mycket om dataSet eftersom jag är av den uppfattning att det är en styggelse, men jag har svårt att se hur du skulle få med den information från din databas i en vanlig SQL fråga. Så jag är nästan helt övertygad att du måste sätta dem programmatiskt efter/innan du hämtar din data.
Du väljer att hämta ett (typat?) dataset med alla lagda beställningar. Sedan lägger du till din nya beställning genom affärslagret genom att först lägga till raden i ditt dataset och sedan köra update med en dataadapter - vad händer då om du har fått in en beställning sedan datan hämtades till din dataset?
Har lite svårt att förstå vad du menar, men menar du att du först hämtar alla gjorda beställningar till ett DataSet och visar dessa för kunden, kunden lägger sedan till de nya beställningar till DataSetet vilket nu kommer att innehålla dels redan gjorda beställningar och de nya beställningar som inte är gjorda än. Och sedan så gör du en Update ner till databasen. Om det är så du menar så verkar det vara ett otroligt omständingt sätt att lägga till nya beställningar till databasen. Varför iall världen vill du blanda in redan gjorda beställningar. Du skall bara skicka ner den nya beställningarn till databasen, vill kunden se sina gammla beställningar så visas de på en Historik sida som är ReadOnly eftersom man inte skall ha möjlighet att ändra i någon redan gjord beställning. Det löser även ditt problem...
- M


