Jag håller på med en liten komponent och trots mitt ihärdiga studerande av 'komponentarkitektur' i VB och COM, kan jag inte komma fram till en vettigt struktur på mitt gränssnitt. COM är lite nytt för mig fortfarande. :)
Jag har funderat i dessa banor, men jag vill inte börja bygga innan jag är säker på hur jag skall göra implementationen:
Komponent
Klassmoduler
Admin
DataHandler
News
Tanken är att Admin skall innehålla metoder som har med administrationen av applikationen att göra. Datahandler skall egentligen bara innehålla två metoder: getConn samt execSql. Vad de gör är väl ganska uppenbart. News innehåller metoder som har med visning, uppdatering, radering och addering av data i applikationen att göra.
Alla anrop från metoderna i Admin och News går direkt till DataHandler som returnerar önskad data/värde.
---
Är tanken helt fel? Skall man tänka i anda banor än i t.ex. ASP-klasser? Är det rätt att ha en DataHandler? Skall jag addera fler lager? :p :)
Ja, det beror kanske lite på hur din applikation ser ut i övrigt? Sköts all databaskommunikation i komponenten eller finns det databas/ADO-kod som ligger utanför komponenten i "ren" ASP?
Om getConn och execSql bara är "tomma" wrappers kring ADO-anropen: Open och Execute så kanske du lika gärna kan utföra dessa anrop "direkt" i din övriga kod? Och om getConn och execSql är de enda metoderna i DataHandler så kanske den rent av är helt onödig?
Dessutom så har ju din komponent direkt tillgång till alla objekt i din omgivande ASP-kod (globala connectionstrings osv ..) om du länkar till ASP-liben vid kompileringen.
Men som sagt, det beror på syftet med komponenten. Sköter komponenten ensam hela datalagret och ASP-koden enbart presentationen? Eller är det lite blandat?
Ja, det beror kanske lite på hur din applikation ser ut i övrigt? Sköts all databaskommunikation i komponenten eller finns det databas/ADO-kod som ligger utanför komponenten i "ren" ASP?
Det är meningen att alla databas/ADO-kod skall huseras i komponenten och att kommunikation med databasen skall gå igenom komponenten, iaf om det har med denna applikation att göra.
niko skrev:
Om getConn och execSql bara är "tomma" wrappers kring ADO-anropen: Open och Execute så kanske du lika gärna kan utföra dessa anrop "direkt" i din övriga kod? Och om getConn och execSql är de enda metoderna i DataHandler så kanske den rent av är helt onödig?
Varför är den onödig? Meningen är att försöka skilja datahanteringen från anropet.
niko skrev:
Dessutom så har ju din komponent direkt tillgång till alla objekt i din omgivande ASP-kod (globala connectionstrings osv ..) om du länkar till ASP-liben vid kompileringen.
Jag vill helst undvika miljö-specifik kod i komponenten, alltså ingen ASP-kod såvida det absolut inte kan undvikas.
niko skrev:
Men som sagt, det beror på syftet med komponenten. Sköter komponenten ensam hela datalagret och ASP-koden enbart presentationen? Eller är det lite blandat?
Som det är tänkt skall väl komponenten sköta all logik och ASP-filerna skall bara anropa metoderna i komponenten. Datat som kommer tillbaks hanteras i ASP-filerna där miljö-specad kod kan användas utan problem.
Det är meningen att alla databas/ADO-kod skall huseras i komponenten och att kommunikation med databasen skall gå igenom komponenten, iaf om det har med denna applikation att göra.
OK. Isåf har jag inga direkta invändningar mot ditt uplägg. :)
OveRRidE skrev:
Varför är den onödig? Meningen är att försöka skilja datahanteringen från anropet.
Nej, isåf är den inte onödig. Jag avsåg det andra scenariot där komponenten var en mindre del av en större webbapplikation och det även skedde databasaccess på andra ställen.
OveRRidE skrev:
Jag vill helst undvika miljö-specifik kod i komponenten, alltså ingen ASP-kod såvida det absolut inte kan undvikas.
Ja. Fast länkning till ASP-liben innebär bara att komponenten har tillgång till/är medveten om globala objekt/inställningar i webbaplikationen/IIS:en utan att dessa hela tiden måste skickas in och ut via metodanrop. Mycket smidigt (enligt mig).
Jag avsåg det andra scenariot där komponenten var en mindre del av en större webbapplikation och det även skedde databasaccess på andra ställen.
Ok, så är inte fallet. Den är ensamstående än så länge. :)
Fast länkning till ASP-liben innebär bara att komponenten har tillgång till/är medveten om globala objekt/inställningar i webbaplikationen/IIS:en utan att dessa hela tiden måste skickas in och ut via metodanrop. Mycket smidigt (enligt mig).
Mjo, men det har jag allt läst i en mycket tjock bok, att man helst skall se till att skilja dessa bitar åt. ;) Men du har rätt i att det är smidigt.
@nders och jag hade en liten sådan diskussion igår, där jag knappt förstod själv vad jag pratade om. :e ;)
Mjo, men det har jag allt läst i en mycket tjock bok, att man helst skall se till att skilja dessa bitar åt.
Mja, möjligtvis om man avser att skriva en komponent som ska vara så generell att den ska gå att använda i helt andra sammanhang? Dvs även i kod som inte kör i IIS:en.
I annat fall är jag nog av den uppfattningen att man ska utnyttja de "finesser" som den miljö man riktar sig emot erbjuder. Annars kan man ju lika gärna koda allt i Java. Och verkligen undvika allt "miljö-specifikt". ;)
Vide: För då har du tillgång till metoderna i hela projektet. Och metoderna finns då inte tillgängliga från ASP-sidorna. Det gör att man då aldrig får för sig att göra ett databasanrop från ASP-sidorna. :)
I vår Databas.bas modul har vi metoder som:
GetConnection
GetRecordset
ExecuteSQL
SaveRecordset
Mycket smidigt att sen använda dem i hela projektet. :)
Vide: För då har du tillgång till metoderna i hela projektet. Och metoderna finns då inte tillgängliga från ASP-sidorna. Det gör att man då aldrig får för sig att göra ett databasanrop från ASP-sidorna. :)
Wf är underbart, här slipper man t.o.m att ställa en fråga, man får svar ändå. :e
Vide: För då har du tillgång till metoderna i hela projektet. Och metoderna finns då inte tillgängliga från ASP-sidorna. Det gör att man då aldrig får för sig att göra ett databasanrop från ASP-sidorna. :)
Wf är underbart, här slipper man t.o.m att ställa en fråga, man får svar ändå. :e
