Hehe erka.. Nej. Det gör jag inte... ;) jag menar det nedersta lagret som har hand om SQL, getPost, getByID eller vad man nu kan tänka sig... jag har skapat en tråd och läst 2/3 av den länken jag fick, som jag har tagit en massa anteckningar ur, men jag kan inte fundera ut hur man ska kompilera in allt i ett, eller om man ska kompilera varje enskilt .cs dokument och lägga allt i bin-mappen... detta är dock det jag tänkte fråga om imorgon ;) och det hör inte så mycket hit, men jag hoppas att jag har fattat det någolunda...
OT
Datalagret med logik och kanske ett DAL :) Objektlager är ett dåligt namn.
Ett råd, skaffa visual studio, student licens 1000:- då slipper du oroa dig för all kompilering. Du kommer aldrig dra nytta av .net om du inte har den enda effektiva utvecklingsmiljön för det. Hur du ska kompilera det, enskilda dll:er eller en gemensam beror helt och hållet på syftet och din arkitektur i sin helhet.
Jo.. Det ska heta Buisness Object DataAccess Skikt.
Jag lägger resten av mina frågor i min tråd...
Som sagt så vet jag inte riktigt hur allt fungerar. Men jag kan tänka mig 3 dller där man kan byta ut en av dem hur som helst eftersom de är enskilda lager. Men det kanske måste vara en stor dll med alla klasser? I så fall får man ju kompilera om den då och då om man bygger ut BODS - till exempel så att BODS går över från att använda MS Access 2002 till MySQL.
Jag vill ha en stor databas med allt innehåll på siten och jag vill skicka GET variabler i adressfältet för att hämta rätt sida "page=5" för att hämta. Den ska kolla om det finns en rad med detta id i databasen och sedan svara med den datan/göra den datan tillgänglig i ett recordset eller datalist.
Osv....
Jag hade inte gjort på det viset, det du kallar "Buisness Object DataAccess" ska enligt mig i praktiken vara sql-frågor som i sin tur anropar ett underliggande generellt applikations ospecifiktlager som tar hand om hämtning, uppdatering, inläggning av data, ett så kallat DAL, Data Access Layer som ska kunnas separeras helt och hållet från övriga applikationen.
Det är i det du ska lägga till funktionalitet för mySQL och inte i ditt affärslager. Ska du bygga ett CMS tycker jag du direkt ska byta från access till mySQL eller MS-SQL
Tror du har snurrat upp namnen lite. Ska du byta från ms access till mySQL behöver du nog göra ändringar även i ditt affärslager data, med tanke på att querys etc kan se lite annorlunda ut.
Hmm, okej... Det är ett lite annorlunda tillvägagångssätt. Du säger att BOD(s) lagret ska ha hand om SQL queries och sedan ska det anropa ett DAL lager, som sedan hämtar datan.
På detta sättet så kommer du ju, när du kompilerar, att ha ditt BODS lager med dina SQL queries som är specifika för MySQL eller MS-SQL, eller Access 2002, eller hur?
Säg att du då byter ut ditt DAL lager till ett annat som använder sig av MySQL, så kommer ju dina frågor från BODS vara felaktiga för den databasen, eller?
Det blir väl så som du säger i din sista mening?
Det stämmer bra att jag borde använda mySQL istället för access, men det känns som det finns oändligt lite information om hur man programmerar ASP .Net i C# med mySQL (det är ju ganska specifikt). Vad är adressen till MSs beskrivning av alla namespaces (det vore snällt om du kunde skicka den)?
Hur jag har tänkt mig efter att ha läst trådarna om det:
Presentationslager
.aspx tillsammans med .aspx.cs, .ascx, .js, .css.
i .aspx.cs står det (för en login app.)
User tempUser = new User();
tempUser.name = Request.Form("usrName");
tempUser.familyName =
...
tempUser.Add;
Affärslager - Buisness Logic Skikt (BLS)
blsThisApp.dll (Ska den vara för sig eller ihopkompilerad med alla andra?)
class User : BODSClass { funktioner som bearbetar datan, sätter parametrar (?)
och skickar till slut anrop till BODS om att BODS
ska skriva datan till databasen och returnera true
om det lyckas. }
Dataaccesslager - Buisness Object DataAccess Skikt (BODS)
bodsThisApp.dll (Ska den vara för sig eller ihopkompilerad med alla andra?)
using System. (här importeras alla namnrymder för att läsa databaser)
class dbUser : Namespace.Data.OleDbData {
//här är jag lite osäker, men här ligger i alla fall en variabel som ser ut så här
public string mySQLStmt = Application["sqlQuery"];
public string AccessStmt = Application["AccessQuery"];
//här kommer en ifsats som kollar vilken av
dessa som innehåller något och använder rätt
funktion för att hämta datan beroende på om det är mySQL eller access.
}
Databasen
Jag menar något i den stilen... stämmer det eller har jag fått det helt fel?
jag vill alltså att mitt nederska lager (3) ska kolla i web.config efter rätt sql fråga så att det
bara är att byta ut den efter vilken data man ska ta fram och sedan skicka fram till presentationslagret.
Jag vill också att BODS ska innehålla en funktion
getData(string sqlQuery)
där den hämtar vad som helst enligt frågan.
Tanken är ju att du ska ha ett DAL som du kan använda på många olika projekt, webbsiter. Det är ju tex en möjlighet att du bygger in stöd för sp's i ditt DAL.
Jag gillar att ha SQL-frågor skillda i ett eget lager, på det viset behöver man inte kompilera om allt om det bara är ändringar i en sqlfråga som ska göras. Till viss mån via sps, Det du surrar om getData är ju en generell applikations ospecifikmetod och bör således inte ligga i det du kallar BODS
Fråga, varför ärver din BLS från din BODSClass ?
Man kan göra på 1000 olika sätt, vissa bättre än andra. Så här funderar mina applikationer
Låt oss säga att jag har en applikation som listar användare
0.Databas
1.DataAccessLayer (DAL)
Generell klass för tex insert,update,delete, hämta ut datatables, datasets etc från databas som specificeras via web.config, har tex en metod som heter executeNonQuery(string query, SqlParameters[] sqlParams).
2.User.Data(Affärslager, Data): Ärver från DAL
Sqlfrågor som tex hämtar en användare, lägger till en användare. har exempelvis en metod som heter updateUser(User u)
3.User.User (Affärslager)
Min user klass med konstruktor, instansvariablar, informationshållare för användare. Har tex en metod som heter UpdateUser():bool som i sin tur anropar updateUser i User.Data
ang. din fråga: du skriver väl också att din User.Data ärver från ditt DAL lager? Det är väl samma sak som vi pratar om?
getData - jo det stämmer. som du kanske hör nu så har jag inte riktigt allt klart för mig, men vad jag tänkte på var en funktion (vad är skillnaden mellan en funktion och metod?) som tar in en sql fråga och retunerar svaret. ungefär som din executeNonQuery, eller kanske en DataSet RetrieveDataSet(sql) funktion.
Jag hade blivit jätteglad om du hade kunnat skicka lite kod att titta på :)...
Jag brukar lära mig bäst enligt detta:
lärare som visar ett exempel, berättar om det och sedan låter mig pröva 1-2 själv. (snabbast)
Försöka klura ut det själv (bäst inlärning :))...
så om du hade kunnat skicka din kod och möjligtvis lite kommentarer om hur man kan kompilera den och få den att fungera :h så skulle jag bli mycket glad.
Mina sql frågor hade jag tänkt ha i mitt lager närmast databasen, det som du kallad DAL och jag kallad BODS lagret.
Det är för att Business Logic Skikt, eller vad jag egentligen kallar affärslagret enbart ska skicka en fråga om vad som ska komma tillbaka, och inte hantera sql. BLS hanterar sql så blir det väl problem om man ska byta ut det understa lagret?
dea90:
nåt i den stilen som jag har bifogat.
det är bara ett exempel, men det är lite snyggare i alla fall. det kanske är roligare om du får göra den själv och säga att du har gjort den själv...
Du behöver inte alltid ha ett affärslager logik utan kan kappsla in det i ett och samma lager.Allt beror på vad man tycker fungerar bra själv.
Dock tycker jag det är klumpigt å ha det på ett sådant sätt du gjort, inte speciellt skalbart och skiktat. Har du ett lager mellan affärslagret och databasen som har som uppgift att ta emot frågor och göra något med dem, kanske returnera kanske exekvera får du större valbarhet. Jag har inte riktigt förstått hur du har tänkt, jag tror du har stirrat dig blind på vad du kallar lagrena och inte vad de egentligen har för uppgift.
Som sagt så har jag inte till 100% förstått logiken bakom detta, och det är just därför jag undrar om du hade kunnat skicka lite kod?
"Har du ett lager mellan affärslagret och databasen som har som uppgift att ta emot frågor" så du menar att lagret precis innan databasen ska få sina sql frågor från affärslagret?
Det här är frågor som ofta återkommer och det svåra är att det inte finns ett rätt svar utan som det redan nämnts finns massa olika lösningar som passar sig bäst för olika situationer.
OM du är ute efter att kolla på kod så kan du slå en titt på .Net petshop 3 från microsoft.
Ingen lysande arkitektur om du frågar mig men den visar ändå på några nyckelfunktioner...
I .Net petshop 3 har Microsoft valt att lägga all sql i respektive Dal. Detta medför sådeles att det bara är ett Dal för just den applikationen och inte ett generellt återanvändbart Dal som man bara kan droppa in dll:n och använda. Dock kan man lyfta in sitt projekt och ändra lite i det om man vill.
Ska man ha ett Dal som är portabelt mellan olika projekt utan att man ska behöva mecka om i det och skriva massa sql har man ett par olika val:
1. Ha sina sql-satser i sitt Affärslager och skicka dessa till sitt Dal, man måste ju ändå skapa ett affärslager per applikation så det begränsar egentligen inte så myket som man kan tycka.
2. Ha sina sql-satser på ett separat ställe (konfig fil, xml, whatever) och indexera och skicka med till sitt Dal.
3. Skapa ett frågegränssnitt och låta sitt Dal generera dynamisk sql. Komplicerat men är man arkitektur och kodfashist så är detta en mycket tillfredställande metod.
Det finns fler sätt men de går jag inte in på närmare nu.
Hoppas att detta redde ut några frågetecken. Nu ska du ta ett steg tillbaka och utvärdera vilket sätt du ska göra det på. Detta är en individuell avvägningsfråga och beror naturligtvis på vilken typ av applikation du ska bygga och hur mycket du vill ska vara återanvändbart mm.
Jag tror att du kommer att välja att gå vidare med någon form av metod 1 hur som helst. Detta kommer att generera fler frågor och tvinga dig att välja mellan nästa väg och så vidare...
705 ms totalt · 4 externa anrop · v20260731065814-full.1dc6f849
