Flerlagrad lösning

Eftersom du använder DataSet(vilket är ett ypperligt val :D ) så bör du använda VS.NET:s adapters istället, annars går syftet med DataSet:s lite förlorad, , så gör såhär istället kompis, radera all denna kod och Öppna Server Explorer som du har på vänster sida i VS.NET, dra in dem tabellerna du vill ha med i ditt projekt så skapas Dataadapters automatiskt , och sen högerklickar du på dataadaptern och väljer configure Dataadapter, och klickar på "Create new stored procedure" , och bara klickar dig vidare så kommer VS.NET hårdkoda INSERT/UPDATE/DELETE/SELECT stored procedures i servern åt dig helt gratis. plus att du får adapters som är färdigskrivna att användas till dessa stored procedures. Och som grädde på moset så behöver du inte skapa dataset:et själv, låt VS.NET göra detta åt dig också, högerklicka bara på adaptern och tryck "Generate DataSet" så får du starkt typat DataSet, där dina tabeller finns representerade. Då slipper du skriva såhär:
myDataGrid.DataSource = ds.Tables[0].DefaultView;
Och kan istället skriva såhär:
myDataGrid.DataSource = ds.dintabell.DefaultView;
Blir lättare att hålla reda på tabellerna då.
:bire

Det där va ju inte så lätt för den ovana :) ... finns det nått på msdn eller liknande om hur man bygger flerlagrade lösningar med vs.net ?

Den metod som Nöff beskriver är säkert en bra metod som gör det hela lätt för dig (vi ska inte ge oss in i klinch om det där igen).

Här finns lite att läsa om flerlagersstrukturer och .NET

Sen kan du ju alltid ta en titt på referensapplikationerna (.net petshop, ibuyspy, .net forums osv...)

Ok, låter som att det inte var en lösning att rekommedera... vore kul att läsa lite om hur ni som är lite insatta bygger era webblösningar ...

Här har du en länk där jag beskriver mitt sätt att bygga fler-lagerlösningar.
http://www.pdc.se/blog/DisplayEntry.aspx?eid=5

Tackar ... fler såndana länkar vore trevligt ... kanske någon tutorial där man kan se hur dom olika lagren jobbar ihop

Denna är ganska intressant :)

PDahlen skrev:

Här har du en länk där jag beskriver mitt sätt att bygga fler-lagerlösningar.
http://www.pdc.se/blog/DisplayEntry.aspx?eid=5

Det har var en bra förklaring tycker jag ... tack

Dessa tycker jag är bra.
http://www.microsoft.com/belux/nl/msdn/community/columns/hyatt/ntier1.mspx
http://www.devx.com/vb2themax/Article/19892/0/page/1

Här är en tutorial där du kan se hur du använder den metod som Nöff beskriver och gör den "flerlagrad"
http://www.15seconds.com/issue/030317.htm

Re: Flerlagrad lösning

maqe skrev:

Hej!

Skulle behöva lite hjälp på traven med att använda mig av lagrade procedurer istället för att ha en massa sql kod i min vanliga kod ...

såhär ser det ut i mitt dataaccess lager:

private SqlCommand CreateSQLCommand(string strSQL)
{
SqlCommand myCommand = new SqlCommand(strSQL, objConnection);
return myCommand;
}

och såhär ser det ut i mitt affärslager:

public DataSet GetEntrys()
{
string strSQL = "SELECT * FROM Forum ORDER BY Id DESC";
return GetNewDataSet(strSQL);
}

och såhär ser det ut i min page_load:

DataSet ds = new DataSet();
try
{
ds = objBLForum.GetEntrys();
objBLForum = null;
myDataGrid.DataSource = ds.Tables[0].DefaultView;
myDataGrid.DataBind();
}
catch (Exception ex)
{
throw ex;
}

Nu skickas ju en string som argument och jag förstår inte hur jag ska göra om jag vill köra en sp istället? Nån som kan komplettera min kod lite kanske...

Hej

Som jag ser det så tillhör inte detta(koden nedan) ditt BL utan DL. Jag tror att BL endast skall innehålla data som är används i ditt program och ingen kod som kan kopplas till DL, detta är hårddraget och delvis fel. Det som är ditt BL i det här fallet är ditt dataset, sen kan du gruppera olika services för att tex validera din data, dessa services hamnar då i ditt BL.

public DataSet GetEntrys() 
{
string strSQL = "SELECT * FROM Forum ORDER BY Id DESC";
return GetNewDataSet(strSQL);
}

Jon skrev:

<<snip>>

Sen kan du ju alltid ta en titt på referensapplikationerna (.net petshop, ibuyspy, .net forums osv...)

Jag tittade på .net petshop 1.5 för ett tag sedan och tyckte det delvis var riktigt illa. Iofs så beror det kanske på vad man vill visa men jag tyckte petshop var hemsk om man vill lära sig hur man separerar lager ifrån varandra.

tex här är lite kod från klassen customer

SqlParameter[] prams = {
				data.MakeInParam("@userid",      SqlDbType.VarChar, 80, userid),

koden behöver ingen kommentar..

EDIT::

Kikade lite mer och jag tar nog tillbaka detta, delvis.. För klassen customer är inget customer object så som jag trodde det var utan det är något helt annat.

Jag tycker det är bättre att kolla på asp.net Starter Kits.

Re: Re: Flerlagrad lösning

Walker skrev:

maqe skrev:

Hej!

Skulle behöva lite hjälp på traven med att använda mig av lagrade procedurer istället för att ha en massa sql kod i min vanliga kod ...

såhär ser det ut i mitt dataaccess lager:

private SqlCommand CreateSQLCommand(string strSQL)
{
SqlCommand myCommand = new SqlCommand(strSQL, objConnection);
return myCommand;
}

och såhär ser det ut i mitt affärslager:

public DataSet GetEntrys()
{
string strSQL = "SELECT * FROM Forum ORDER BY Id DESC";
return GetNewDataSet(strSQL);
}

och såhär ser det ut i min page_load:

DataSet ds = new DataSet();
try
{
ds = objBLForum.GetEntrys();
objBLForum = null;
myDataGrid.DataSource = ds.Tables[0].DefaultView;
myDataGrid.DataBind();
}
catch (Exception ex)
{
throw ex;
}

Nu skickas ju en string som argument och jag förstår inte hur jag ska göra om jag vill köra en sp istället? Nån som kan komplettera min kod lite kanske...

Hej

Som jag ser det så tillhör inte detta(koden nedan) ditt BL utan DL. Jag tror att BL endast skall innehålla data som är används i ditt program och ingen kod som kan kopplas till DL, detta är hårddraget och delvis fel. Det som är ditt BL i det här fallet är ditt dataset, sen kan du gruppera olika services för att tex validera din data, dessa services hamnar då i ditt BL.

public DataSet GetEntrys() 
{
string strSQL = "SELECT * FROM Forum ORDER BY Id DESC";
return GetNewDataSet(strSQL);
}

EDIT:: dumt av mig att inte försöka svara på frågan..

Men jag ser inget som helst fel med detta, förutom att de kan vara fel att säga att getEntrys tillhör BL. För stt själv se hur man skulle komma runt det så började jag bygga något som använde dataset som BL och det blir bara att man skickar datasetet vidare till nästa lager som i sin tur skickar vidare det till nästa lager och jag tycker inte man vinner något på det.

Jag tittade på .net petshop 1.5 för ett tag sedan och tyckte det delvis var riktigt illa. Iofs så beror det kanske på vad man vill visa men jag tyckte petshop var hemsk om man vill lära sig hur man separerar lager ifrån varandra.

Ja dom tidiga implementationerna är riktigt hemska!
Petshop 3 är lite bättre och har IMHO en ganska bra lagerstruktur. Problemet med den är att den är väldigt jobbig att underhålla och förändra.

Om den väldigt jobbig att underhålla och förändra har jag svårt att se att den har en bra struktur. Hur motiverar du den som bra? Jag har inte kollat på denna implementation så jag är bara nyfiken.

Motivationen är att det syns väldigt tydligt vilka lager som finns och hur data skickas mellan dem. Den visar också hur ett DAL kan konstrueras. Sen skulle jag som sagt inte använda den till något större men den illustrerar några grundprinciper för nybörjaren.

Ett problem som ofta (alltid?) föreligger är att man till sist får välja mellan effektivitet och underhållbarhet.

Vill man få ett system som är lätt att underhålla skulle jag använda en o/r mapper och skippa stored procedures. Systemet kommer att bli lite långsammare men det är IMHO på pappret. Har aldrig upplevt denna slöhet själv. Men det där är det lite religion över ;)

Just nu använder jag en o/r mapper nästan överallt och vid specialfunktioner och tidskritiska funktioner låter jag mappern agera DAL rätt av och kör en/flera SP.

Man kan missionera och dikutera vilka lösningar som är bäst i all evinnerlighet men i min verklighet får jag inte alltid bestämma och måste anpassa mig till befintliga databaser och system allt som oftast. Då passar lösningen ovan väldigt bra för mig!