webForumDet fria alternativet

Hur använda abstract class om min klass redan ärver från t.ex. System.Web.UI.Page?

.NET

10 svar · 426 visningar · startad av CokeLight

Medlem sedan juni 2000504 inlägg
Frågan#1

Hejsan,

Jag har en databas-klass (DbObject.cs) som är definierad som abstract, och eftersom jag måste ärva den så måste jag ju typ skriva

public class dbtest : ns1.ns2.DbObject

eller hur...? Men hur gör jag då om jag skapar en testklass som vanligt som då automatiskt ärver från t.ex

public class dbtest : System.Web.UI.Page

Hur kan man lösa detta...? Det blir en krock ju, menar jag mellan Page arvet och DbOjbect arvet... (Läste lite om att göra interface som på sätt o vis kunde "ersätta" multiple inheritance, eller nåt sånt, men det verkar lite mycket jobb för nåt sånt här trivialt...?)

(Alltså, jag vill i princip bara sätta connection-strängen som är definierad i DbObject via min nya testklass, dbtest.cs, o använda lite andra metoder.. :)

Mvh

Medlem sedan dec. 19991 072 inlägg
#2

Oftast så vill man inte ha sitt DAL som basklass utan som ett eget projekt (DAL blir ett eget skikt).

Hur som helst så borde du kunna ärva ner Page i din DB-klass. Sen ärver du ner DB-klassen i din "riktiga" webforms-klass.

Medlem sedan juni 2000504 inlägg
#3

Hej Fredrik, tack för svaret.. fast jag är inte säker på att jag förstod såsom du menade.. :) DAL är min DbObject.cs antar jag (?). Och den ska man ha som eget projekt. Det blir väl en ny dll då som man ska ange referens till då eller..? Är det för att man ska kunna återanvända den i andra webbapplikationer?

Och du menar att jag låter DbObject.cs (min DAL?) ärva System.Web.UI.Page? och sen så ärver min testklass DbOjbect..? a jo, det ju gå tror jag.. just nu så ärver ju inte DbObject nåt..

(Fast du lät lite tveksam, ungefär som att du själv kanske inte skulle gjort så...? Finns andra sätt? :) ) Tack i alla fall.. ska återkomma ifall det inte funkar..

Mvh

Medlem sedan dec. 19991 072 inlägg
#4

Hej igen,

Ja, jag själv vill ha mitt DAL som ett eget skikt. Detta lägger jag ofast som ett eget projekt så att det som sagt blir en egen DLL med. Själva referensen kan du dock sätta på projektet så att du kan debugga koden direkt.

Anledningen att jag gör så är att jag dels vill kunna återanvända mitt DAL i andra projekt, men även att jag vill ha ett flexibelt DAL som ska fungera fristående från mina övriga domän-objekt (BL).

Ett alternativt sätt var som sagt att låta db-klassen ärva från "Page" och sen låta din webform ärva från DB-klassen. Men det är som sagt inget som jag skulle rekommendera.

Medlem sedan juni 2000504 inlägg
#5

hej, a just det.. kom på precis tror jag.. om DbObject.cs ärver Page går det väl rent tekniskt men då blir det väl en röra.. poängen var väl att man skulle separera GUI, o DB osv.. tänkte inte på det..

Så om jag vill anropa en stored procedure (eller nån annan db-relaterad grej) med en knapptryckning, så har jag t.ex. en knapp i MittGui.aspx, som har en code-behind, MittGui.cs. Är det så att jag då ska ha en modul, typ MellanLager.cs, och det är den som ärver från DbObject.cs och på sätt kommer åt alla metoder som finns där? Om det är rätt hittils, ska jag då instansiera MellanLager.cs i MittGui.cs för att eventet ska vidarebefordas på nåt sätt till MellanLager.cs...?

Om det finns andra förslag så provar jag gärna dem.. :) Upptäckte att det var ganska stor skillnad mellan att läsa om nåt i teorin och prova i praktiken.. :)

Medlem sedan dec. 19991 072 inlägg
#6

Är det så att jag då ska ha en modul, typ MellanLager.cs, och det är den som ärver från DbObject.cs och på sätt kommer åt alla metoder som finns där?

Nja. Inte riktigt så heller :)

DB-skiktet ska precis som du säger vara separerat från GUI-koden. Därför läggs den som ett eget projekt.
För att använda sig av det använder du inte något arv alls utan bara en vanlig instans.

DBLogic myDBLogc = new DBLogic();
myDBLogic.Execute(SP, Args);

Sen kan du självklart välja att ha en basklass för dina BO där delar av denna kod wrappas in. Men själva anropet till DB-klassen görs alltså inte med något arv.

Medlem sedan juni 2000504 inlägg
#7

Hej Fredrik, tack för dina svar.. :) okay, så inget arv.. jag tittade nämligen på lite kod nånstans och då hade de gjort en DB-klass som var fin, och även satt den som abstract.. så då verkade det som att man var tvungen att ärva.. men man kan ju lika gärna skapa instans.. jag ser ändå inte vitsen med att den ska va abstract just nu.. ska fundera lite till.. men annars är jag nog nöjd.. :)

tack igen

Medlem sedan juli 20011 304 inlägg
#8

Det är vanligt att man har en abstrakt basklass för sitt dataaccesslager. Där definierar man alla metoder som skall finnas och kunna användas, men den kan egentligen inte utföra något. Det gör man när man ärver den gemensamma logiken till underklasser som t.ex går mot olika datakällor och därmed använder olika klasser för dataåtkomst. Sql-anropen skiljer sig ju som bekant mellan sql-server, access, mysql och oracle. Även Connectionobjekt mm skiljer sig.

Medlem sedan juni 2000504 inlägg
#9

Hej Jon, såg inte ditt svar förrän nu... hmm.. aha.. så du har en lösning med abstract ändå...? har du nåt exempel med pseudokod hur du skulle lägga upp ett scenario då, där man har ett db-anrop från nåt GUI, och där man använder en abstract basklass...? Alltså en kort beskrivning hur du skulle göra... vilka klasser som ingår och hur de ärver...?

Medlem sedan juli 20011 304 inlägg
#10

Oj. Det är ganska stort och ganska mycket kod men jag kan försöka. Men kom ihåg att detta bara är ett sätt att göra det på. Det finns fler sätt och vissa tycker att vissa är bättre och andra är sämre.

1. Klassen DAL, abstrakt basklass för de olika databasmotorer vi vill stödja. Klassen tar emot en connectionstring som den skall använda. Det finns massa interna metoder som t.ex skapar en ny connection, exekverar en sql fråga och lämnar tillbaka ett dataset eller en datareader mm. Generella typer användes, som IDbConnection och IDbCommand.

2. Klassen DALSqlServer som ärver av DAL. Denna klass har precis samma metoder dom DAL fast den skapar SqlConnection och SqlCommand.

3, Klassen DALMySql, Fungerar precis som DALSqlServer fast den använder naturligtvis något som fungerar för MySql

4. En Masterklass, DALMaster som väljer rätt dal, kanske utifrån en key i web.config

5. din codebehind eller annan sida som vill använda ditt Dal. lite pseudokod skulle kunna fungera ungefär såhär:

DALMaster myDal = new DALMaster();
myDal.GetDataSet("Select * From Tabell");

DALMaster kolla i detta läget i web.config och ser att du använder mysql. Den skapar så:
DALMySql dal = new DALMySql("Connectionstring");
Return dal.ExecuteDataSet(sqlsatsen);

Väldigt väldigt förenklat skulle man kunna göra något sådant. Sen borde man kanske generera sql från de olika klasserna eller DALMaster. Videre så lär man vilja stödja stored procedures mm.

Men gör man på detta sättet behöver man ju förhoppningsvis bara göra det en gång och sedan lan man lyfta in sitt DAL i alla sina projekt.

Det känns som du är ute efter hur och varför abstrakt klass om jag förstår det hela rätt? Som jag ser det så är de två strörsta fördelarna i detta upplägg:

1. Alla databasmotorer som ärver från DAL måste se ut på ett visst sätt. Detta underlättar underhåll, läsbarhet, skalbarhet och felsökning.

2. DAL innehåller kod som annars skulle behöva upprepas i varje databasmotor.

Men om man inte planerar att stödja flera databaser finns i detta fallet ingen anledning till att ha en abstrakt basklass...

Medlem sedan juni 2000504 inlägg
#11

ah, suveränt, suveränt.. jättebra förklarat.. nu är jag med på varför abstract.. så "slutanvändaren" jobbar alltså bara med DALMaster, som kollar av om MySQL eller SQLServer körs utifrån t.ex. webconfig (så att man inte behöver skicka in nån parameter).. sen anropas automatiskt t.ex. DALMySql som då har ärvt från den mer generella DAL.. oki.. jag fick mycket mer förklarat än vad jag förväntade mig.. :)

ah, och nu fattar jag också hur mitt GUI ska interagera med db-klassen... Det var ju bara DAL som var abstract.. DALMaster är ju en "vanlig" klass och kan instansieras varifrån som helst.. okay, a men nu tror jag att jag fattar.. tack så mycket :)

253 ms totalt · 4 externa anrop · v20260731065814-full.1dc6f849
122 ms — deklarationer (db)
0 ms — hämta statistik (cache)
129 ms — hämta tråd, inlägg och bilagor (db)
116 ms — ändringar (db)