147 svar · 8 229 visningar · startad av kristoffer · sida 2 av 8
nja...
BODS ärver ifrån OleDBData.
BLS instansierar BODS och anropar metoder i denna.
BLS skall inte behöva känna till hur data skall hämtas det är BODS jobb.
BLS anropar en metod i BODS som t.ex heter BODS.GetAllUsers
BODS använder sig av de ärvda metoderna och properties från OleDbData för att hämta datat och returnera resultatet till BLS.
Annars är du på spåret!
Jag trodde BODS i detta fallet var Icaaq.OleDbData :o
och BLS ärvde BODS egenskaper eller får jag gå och sova lite nu...
Natti natti :-)
BODS ärver Icaaq.OleDbData. BOL anropar BODS.
Du skulle kunna göra på ditt sätt men det blir renare skiktning på detta sätt.
Ok....jag testar igen :) och denna gång på att definiera vilka classer man ska anpassa för att detta ska gå i lås
- Icaaq.OleDbData (anpassar man inte efter någon class)
- BODS som ärver Icaaq.OleDbData (anpassar man så att rätt data hämtas och förs in apropå vad BLS vill)
- BLS (anpassas efter vad PS vill göra)
- PS (presenterar vad BLS BODS har sagt till Icaaq.OleDbData att hämta/fört in i databasen)
Rätt? mvh icaaq
Perfekt!
Weeeeeeeeeeeee!!!!!!!
Då är det bara att börja bygga......men jag tar nog papper och penna först :)
Tack, och det känns nog som jag återkommer ;)
mvh icaaq
Förstår inte frågan riktigt. Om du menar sättet att ärva in en generell databasklass så får du kalla den vad du vill :)
Har inte sett ett bra namn på det.
Jag menar om det fanns nått namn på denna 4-skikts metod ?
Men nu när du ändå tar upp det vad skulle ni kalla classerna?
mvh icaaq
På fråga ett svarar jag : vet inte vad man kan kalla denna metod.
Fråga två så skulle jag på något sätt knyta ihop Business logic klassen med dess databasklass typ namge dem så här : clsUser och dbClsUser.
Happy coding :)
Japp, jag gör även så...
har diskuterat mitt sätt tidigare i:
http://www.webforum.nu/showthread.php?s=&postid=490461#post490461
Det blev lite vi i femman stuk på det där svaret ;) så vi låter nån annan femteklassare svara på fråga ett. Om nån kan det.
Tack för all hjälp and "Happy coding to u too" :)
mvh icaaq
Den skiktningsmetod som fredrik kör kallar ADB-arkitektur för Process Facade/Use Case Facade Pattern (tror jag)
Bygger på att man utgår från en process eller ett use case för att definiera en process/flöde i applikationen.
Då lägger man till ett skikt till i den lösningen som icaaq tittar på:
Presentationsskikt -> Fasadskikt -> Business logic skikt -> Business Data Object -> Databas
Denna lösning tycker jag personligen är snyggast för lite större applikationer. Dock kan det bli lite anarki i fasadobjekten. Eller vilken erfarenhet har du av detta Fredrik?
I större applikationer där klienten består av flera olika enheter där varje enhet behöver för/efter-behandla affärs-logiken fungerar det kanon. Då kan varje del själv göra nödvändiga förändringar och bearbeta om kod, exempelvis data för en "Datagrid" som kan behandlas lite olika i web/winforms tex.
Bygger man däremot enbart en webforms-lösning tycker jag att det skiktet kan tas bort, då det inte fyller någon direkt funktion.
Hur delar du upp dina fasader? Har du en fasad per enhet?
MT
Jag hoppar in med vad man kan kalla ett exempel, Och det jag vill veta är återigen om jag tänkt rätt. Detta är ett exempel på hur jag tänkt
icaaq.aspx
Där har jag en label som heter newsHead (en rubrik till en nyhet)
icaaq.aspx.cs
Där sätter jag värdet på min label genom att först initera classen News()
[red]
News myNews = new News()
[/red]
Sen tilldelar jag den värdet
[red]
newsHead.Text = myNews.Head
[/red]
BLS.cs
Där har jag själva News classen som i construktorn skickar min ConnectionString och mitt SqlStatement som tar fram den senaste nyhetens rubrik till BODS.
[red]
public class News()
{
private string _head;
string myConnection = Application[”connString”].ToString();
string SqlStatement = “SELECT blablabla”;
OleDbDataReader DataReader = RetriveDataReader(myConnection, SqlStatement);
if(DataReader.Read)
{
_head = Test.DataReader[“newshead”].ToString();
}
DataReader.Close();
public string Head()
{
get
{
return = _head;
}
}
}
[/red]
Här kan jag även anpassa i detta fall texten t.ex göra nån replace.
BODS.cs
Där ärver BODS Icaaq.OleDbData´s egenskaper och returnerar en DataReader till classen News()
[red]
public class Test : Icaaq.Data.OleDbData
{
public DataReader RetriveDataReader(myConnection, SqlStatement);
{
using(DataReader datareader = RetriveDataReader(SqlStatement))
{
return datareader;
}
}
}
[/red]
Icaaq.OleDbData
Här har jag alla databasanrop
[red]
protected OleDbDataReader RetriveDataReader(string SqlStatement)
{
OleDbDataReader DataReader;
Connection.Open();
OleDbCommand Command = BuildCommand(SqlStatement);
DataReader = Command.ExecuteReader(CommandBehavior.CloseConnection);
return DataReader;
}
[/red]
OBS.Denna funkar ju så klart inte men det är tankesättet jag är vill veta är rätt
mvh icaaq
BLS bör inte hantera sql statements eller datareaders etc. Denna hantering bör ligga i BODS.
tänk att du skapar en metod i BLS som heter GetNewsHeader
GetNewsHeader anropar i sin tur en metod i BODS som även den kan heta GetNewsHeader. DENNA GetNewsHeader sätter rätt sql statement och får tillbaka en datareader.
BLS skall endast ta emot resultatet från BODS GetNewsHEader i form av en xml sträng etc. Den skall ej "känna till" slq satser, datareades etc
h0lger: Menar du att SQL-satser ska ligga i affärslagret (kompilerade dll-filer)?
Det är ju bättre att de ligger ett lager upp så att de kan ändras vid behov, tycker jag. Eller har jag missupfattat dig?
Nu ska vi inte börja att blanda in xml i det hela.... ;) men ok jag ska läsa ditt inlägg här ovanför ett hundratal gånger så kanske jag fattar vad du menar.....
tack
Nej SQL koden bör ligga i dbUser lagret eller BODS lagret.