Gör om gör rätt, eller?

Jag använder din class som du skrev i en annan tråd som jag hade. Problemet ligger i när jag ska försöka uppdatera något jag vet måste ju returera något från DAL -> BLL -> UI men jag vet inte vad. ExecuteNonQuery(command) brukar man ju returera men det är lite svårt när en sådan sak ser ut så här för mig när jag använder din class:
int ExecuteNonQuery = new DataAccess().ExecuteNoResult(ConfigurationManager.AppSettings["DatabaseConnection"], objCommand);

Ska jag returera ExecuteNonQuery som int? Fungerar det?

thevice skrev:

Jag använder din class som du skrev i en annan tråd som jag hade. Problemet ligger i när jag ska försöka uppdatera något jag vet måste ju returera något från DAL -> BLL -> UI men jag vet inte vad. ExecuteNonQuery(command) brukar man ju returera men det är lite svårt när en sådan sak ser ut så här för mig när jag använder din class:
int ExecuteNonQuery = new DataAccess().ExecuteNoResult(ConfigurationManager.AppSettings["DatabaseConnection"], objCommand);

Ska jag returera ExecuteNonQuery som int? Fungerar det?

Det beror ju på vad mottagaren förväntar sig för värdetyp ;)

Hehe så långt har jag inte tänkt. :P Det ända jag vill är att uppdatera databasen sedan om det är något som är fel så ska det retureas något så sidan fattar att något gick fel och kan skriva ut ett felmeddelande. Lite luddigt förklarat men hoppas ni förstår. ;P

thevice skrev:

Hehe så långt har jag inte tänkt. Det ända jag vill är att uppdatera databasen sedan om det är något som är fel så ska det retureas något så sidan fattar att något gick fel och kan skriva ut ett felmeddelande. Lite luddigt förklarat men hoppas ni förstår. ;P

Om uppdateringen går bra så kommer ju ExecuteNoQuery() att returner antalet rader som har blivit uppdaterade, men du kan ju även utgå ifrån att din SQLsats är okej, och om uppdateringen inte går bra så får de ett exception kastat på dig, och går det bra så behöver du ju inte returnera något från di ExecuteNoQuery().

Så du utgår ifrån att det alltid går bra, och skulle du få ett fel så visar du en felsida där det står att något fel har inträffat.

- M

-> Gladh
Jag följer tråden lite lätt men jag har en liten fundering. Jag vet inte om jag förstod dig rätt men är det en tvåskiktad lösning du pratar om här i slutet? Det känns som att du blandar in DAL-metoder i BLL och det känns inte rent spontant bra? Varför inte ha BLL fritt från DAL?

Angånde din fråga för ett tag sedan om storeprocedur-paket. Det är bara att skapa en procedur med flera olika procedurer i. Exempelvis:

CREATE Procedure proc_PaketProcedur
(
	 @DinaInparametrar
)
AS
	EXEC Databas.dbo.proc_X
	EXEC Databas.dbo.proc_Y
	...
GO

Resultatet från paketet kastar du sedan in i ett dataset och där har du sedan dina tabeller.

lukaspojken skrev:

Jag följer tråden lite lätt men jag har en liten fundering. Jag vet inte om jag förstod dig rätt men är det en tvåskiktad lösning du pratar om här i slutet? Det känns som att du blandar in DAL-metoder i BLL och det känns inte rent spontant bra? Varför inte ha BLL fritt från DAL?

Det beror på hur man definerar sitt DAL, mitt DAL sköter endast databasacces och känner inte till något om entiteter överhuvudtaget, utan tar emot ett Command objekt och kan returnerer DataTable/DataReader/DataSet. Det som jag har som inte fanns med i exemplet är en O/RMapper som ligger mellan BLL och DAL, så BLL anropar O/RMappern som anropar DAL som skickar tillbaka ett DataReader/DataTable och så mappar O/RMappern om data till entiteter som BLL får tillbaka. Så det blir 4 skikt, och så hade jag löstdet även om jag inte hade haft någon O/RMapper, så fall hade jag skapat ett lager mellan BLL och DAL med en massa factories som hade kallat DAL:et och sedan hade jag skrivet mappningen till objekten själv i varje factory.

Men i exemplet där man bara har 3 lager (inte 2) så blir det UI->BLL->DAL, och då får BLL ta hand om att skapa inparameter till DAL:et och mappa om Datan från DAL:et till entiteterna.

Mitt DAL är helt fristående från all projekt, vilket gör att jag kan implementera samma assembly i alla min projekt, jag behöver alltså aldrig skriva någon ny kod för att anropa en databas och hämta data, utan skickar bara in ett/flera Command för att exekvera i DAL:et, men någonstans måste Command-objektet skapas, och har man bara 3 skikt så blir det i BLL.

lukaspojken skrev:

Resultatet från paketet kastar du sedan in i ett dataset och där har du sedan dina tabeller.

Okej, skall kolla lite mer på det, och se vad det är för datamängd som kommer tillbaka, spontant så tror jag att jag får flera olika resultatset tillbaka och att DataSetet omvandlar det till olika datatables i sin kod. Man slipper ju på det viset en massa anrop till databasen om man vill fylla ett objekt och dess under objekt direkt vid instansiering istället för lazyloading...

- M

Hej igen,

Jag skulle behöva lite kommentarer på hur jag löser mitt DAL. Det känns nästan som om det är för "lätt". Lägger upp koden på en funktion som jag gjorde för inte så länge sen.

DAL
http://www.aspkoll.se/code/?id=94

BLL
http://www.aspkoll.se/code/?id=95

UI
http://www.aspkoll.se/code/?id=97

Det kanske är lite väl mycket kod att kolla igenom, men vore tacksam ifall någon kunde skumma igenom och komma med idéer.

/ Timmie

Du gör som jag gjorde tidigare och jag tycker det är fel. Ett Data Access Layer ska endast hantera just data access... du behöver egentligen bara ett enda DAL-fil till alla dina sidor. Gör om alla frågor till Stored Procedures så kan du från BLL skicka med namnet på din sp som du sedan kör i dal och returnerar ett datatable till din BLL där du hanterar mappning.

CatZ skrev:

Du gör som jag gjorde tidigare och jag tycker det är fel. Ett Data Access Layer ska endast hantera just data access... du behöver egentligen bara ett enda DAL-fil till alla dina sidor. Gör om alla frågor till Stored Procedures så kan du från BLL skicka med namnet på din sp som du sedan kör i dal och returnerar ett datatable till din BLL där du hanterar mappning.

Hm jag tänker nog mera att BLL inte skall skicka med nån stored-procedure specifikation, vill ha så täta skott som möjligt, jag vill kunna byta ut min db mot en simpel .mdf kanske, BLL ska inte behöva bry sig. Fast det är ju bara min högst personliga åsikt, finns säkert andra som är mer insatta i ämnet som kan ge en mer officiell guideline.

/Freguz

freguz skrev:

Hm jag tänker nog mera att BLL inte skall skicka med nån stored-procedure specifikation, vill ha så täta skott som möjligt, jag vill kunna byta ut min db mot en simpel .mdf kanske, BLL ska inte behöva bry sig. Fast det är ju bara min högst personliga åsikt, finns säkert andra som är mer insatta i ämnet som kan ge en mer officiell guideline.

/Freguz

Från att ha haft 10 olika DAL filer på närmare 2000 rader kod använder jag nu endast 1 fil på 123 rader kod. 1 funktion för update / insert, en funktion för att hämta ett datatable och en funktion för att hämta senaste id jag skapade med en insert.

Allt beror på hur man vill definera sina lager och hur många lager man vill ha. Själv har jag precis som Catz endast ett DAL som jag återanvänder i alla mina projekt, där jag skickar in ett IDbCommand objekt och får tillbaka DataTable/DataReader.

Det betyder att mitt DAL är generellt för alla mina projekt och kan inte innehålla några omvandlingar till entiteter.

BLL bör inte innehålla några storprocedure anrop utan bör precis som thevice har gjort i sin kod, endast innehälla metodanrop till något som kan ge mig dessa entiteter, det är ju inte BLL uppgift att skapa "Databas specific" information.

Så hur gör man då?

Tja antingen så skapar man DAL:et och BLL som thevice har gjort och skriver om sitt DAL för varje nytt projekt, eller så skapar man databasspecifia saker i sitt BLL och har ett och samma DAL för alla sina projekt (mindre kod) eftersom du ändå måste skapa specifika BLL för alla projekt, men kan återanvända DAL:et.

Eller så lägger man till ytterligare ett lager imellan BLL och DAL, där du helt enkelt låter BLL kalla på din OR-Mapper som i sin tur kallar på DAL:et. Din OR-Mapper kan vara generell eller så kan den vara specifik för varje projekt. Detta är en lösning som jag skulle förslå, då du har samma DAL för alla projekt, och ditt BLL innehåller ingen "databas specifik logik", ditt "OR-Mapper" lager tar hand om all information för att mappa data till entiteter.

- M