26. januar 2005 - 09:54Der er
38 kommentarer og 2 løsninger
OOAD med asp.net?
hej,
jeg har lavet en webapplikation og er nu i gang med at dokumentere den. ooad. unified process. uml.
use cases. system sekvens diagrammer. domain model. interaktionsdiagrammer. klasse diagrammer. osv osv
og jeg forsøger at følge principperne så godt som muligt bag ooad tankegangen, har bla lavet en facade til databasen.
men jeg synes, at user interfacet gør det svært at lave et ideelt design.
gælder der 'særlige' regler, når man skal lave webapplikationer??
som det er nu: jeg har nogle webforms som er user interfacet til brugeren. fx er der en der hedder tilmeld.aspx og en der hedder soeg.aspx - jeg har så i VS.NET lavet to klasser der hedder tilmeld.cs og soeg.cs.
jeg sidder og udvikler på localhost. når jeg skal have det op at køre på serveren skal man bare lige kompile koden først. så smider man alle aspx'er op på serveren, og det gør man også med den .dll der kom ud af kompileringen. så der er ingen .cs filer på serveren. kun aspx'er og en .dll - ved ikke om der er en smartere måde at gøre det på?
men for at give et eksempel fra koden med soeg.aspx og soeg.cs:
brugeren indtaster søgekriterier i soeg.aspx. der er nogle TextBoxes og der er nogle DropDownLister. disse er alle erklæret i soeg.cs som også har en eventhandler for den button brugeren trykker på når der skal søges.
soeg.cs opretter så en DbHandler dbTest = new DbHandler(); og kalder en funktion i DbHandler i klassen som returnerer søgeresultaterne, som så vises på soeg.aspx.
sådan er det for alle siderne brugeren kan komme ind på - de har en aspx og de har en .cs.
ved godt det er et lidt abtstrakt spørgsmål måske, men i må spørge løs hvis det er. håber at få noget input :-)
Denne side indeholder artikler med forskellige perspektiver på Identity & Access Management i private og offentlige organisationer. Artiklerne behandler aktuelle IAM-emner og leveres af producenter, rådgivere og implementeringspartnere.
husk også, at soeg.cs ikke som sådan er din klasse. Det er bare en tekstfil klassen ligger i. Der kan godt være mange klasser i en enkelt tekstfil, og med .net 2.0 kan man endda splitte en klasse over flere filer.
arne_v >> jeg har en domain model, som indeholder konceptuelle klasser med associationer og attributer. det vigtigste har dog været at identificere konceptuelle klasser. for mange associationer gør mere skade end de gør gavn (fra "applying uml and patterns" - craig larman).
>>Har du en decideret domain model med klasser for hver tabel eller er det bare web kontrol---SQL---database ?
så vidt jeg har forstået skal man undgå at komme ind på databasen i en domain model? men hvor skal det så ske? jeg vil gerne lave et E/R diagram for databasen, men ved ikke helt hvor det hører til...
DbHandler har en en række funktioner, som returnerer forskelligt. Det er ikke alle sammen, som har en returtype, det gælder for dem som der er INSERT funktioner.
arne_v >> jeg tror ikke vi har samme forståelse for en domain model :-) jeg anvender en domain model ud fra følgende (citat fra applying uml and patterns" - craig larman, side 128):
"The quintessential object-oriented step in analysis or investigation is the decomposition of a domain of interest into individual conceptual classes or objects - the things we are aware of. A domain model is a visual representation of conceptual classes or real-world objects in a domain of interest".
Efterfølgende giver han et eksempel på en domain model (fra et supermarked). Klasserne er som følger: Sale. Payment. Register. Store. Item. Sales LineItem. Manager. Cashier. Customer. Product Catalog.
Det var de fleste af dem. Ud fra eksemplet forstår jeg det sådan, at man ikke skal helt ned på database niveau i en domain model. Er det en ukorrekt forståelse?
cyberfessor >> Ja, jeg har noget lignende. I min webapplikation er der: Medarbejder. Manager. Admin. Vare. VareBeskrivelse. Profil. Log. (Er faktisk ikke sikker på om denne er en konceptuel klasse).
Det var lige nogle af mine konceptuelle klasser i domain modellen.
Du skal ikke ned og tænke i tabeller i en domain model.
Klasserne i en domain model behøver ikke nødvendigvis at ende op i databasen.
Men efter at du har lavet din model skal den jo implementeres.
Og mine kommentarer går på den del af din domain model som du "persisterer", som det så flot hedder i bøgerne.
Implementer du alle data klasserne fra din domain model og bruger dem i dit data lag eller bruger du et relationelt interface (ADO.NET eller dine klasser ovenpå ADO.NET).
Som jeg forstod en af dine kommentarer, så er det det sidste.
Og så mener jeg at du bliver nødt til at skrive lidt om det.
Der kan være mange gode grund etil at vælge det. Bl.a. performance. Men der er ikke den direkte sammenhæng mellem din domain model og implementeringen.
>>Men der er ikke den direkte sammenhæng mellem din domain model og implementeringen.
Det har du ret i, her er lige et citat der bekræfter det:
"A domain model, as shown in Figure 10.2, is a visualization of things in the real-world domain of interest, not of software components such as Java or C++ class (see Figure 10.3), or software objects with responsibilities." (s.130).
Men domain modellen er god som inspiration når koden implementeres.
>> Implementer du alle data klasserne fra din domain model og bruger dem i dit data lag eller bruger du et relationelt interface (ADO.NET eller dine klasser ovenpå ADO.NET).
Som jeg forstod en af dine kommentarer, så er det det sidste.
Ja, det har du ret i. Det er sådan det fungerer :o)
Kommer helt an på hvilke data det er.. men hvis det f.eks. er et grid over alle medarbejderne, ville det så ikke skabe mere konsistens hvis du havde et array af medarbejder-objecter som du bindede til dit grid?
Jeg mener, hvis man vælger at bruge Businnes Objects, bør man ikke gøre det konsekvent hver gang så?
cs: namespace Test.Code { public class Search { Page_Load; En EventHandler til at starte en søgning når der klikkes på button i aspx; DbHandler DbTest = new DbHandler; dbTest.Soeg(Parametre); Plus kode til at binde søgeresultater til datagrid; Plus andet funktionalitet; } }
Så jeg forstår ikke helt hvad du mener med >>Jeg mener, hvis man vælger at bruge Businnes Objects, bør man ikke gøre det konsekvent hver gang så?
Det at jeg anvender business objekter var for at slippe for at bruge codebehinds, så skal man flytte alle .cs filerne med over på serveren så vidt jeg har fortået. med business objekter smider man bare den compilede .dll over og så kører det :-) men det er vist ikke helt det du mente med din kommentar?
wel... nu er ovenstående klasse det man vil kalde for en codebehind, så det slipper du aldrig for at bruge.
Det er rigtigt, at VS bruger termen codebehind til at skabe en relation mellen en aspx-fil og cs/vb-fil, men i sin enkelthed er codebehind den klasse som aspx-klassen arver fra (husk på at aspx-siden også blive compilet til en klasse). Så om man bruger BO eller ej, kan man altid nøjes med at uploade dll-filen.
Jeg vil mene at man ikke skal blande BL ind i sit DAL. Åhja... UI, CB, BO, BL, DAL... det er vist ikke så længe siden vi havde den diskussion. Kunne være jeg bare skulle blande mig udenom :P
En farve A2 printer er en god ting til store diagrammer !
:-)
Reverse engineered klasse diagrammer er tit ubrugelige fordi der er for meget info på dem.
Måske kan du strukturere det lidt: - et diagram som viser alle pakker - et diagram per pakker som viser klasser (uden at vise felter & metoder) - et diagram for hver vigtig gruppe af klasser som viser de klasser med felter og metoder
UI = User Interface CB = Code Behind BO = Business Objects BL = Business Logic DAL = Data Layer Access
ja... det er ikke nemt altid at dele det klart op. Det var også det diskussionen dengang kørte op. Om ens codebehind overhovedet kan ses som en form for Business Logic, og ikke bare en form for Presentation Logic. Et system som STRUTS laver en noget mere klar opdeling.
Men som arne så fint indledte med at sige
Der er ikke specielle regler for web applikationer.
:)
så hvorfor blive gråhårede over noget vi bare kan smile til og sige, "nu gør jeg det på MIN måde" :)
3) Medarbejder-klassen (BO) har altså en statisk metode, Match, som generer en sql-string baseret på filteret og eksekverer det igennem DAL'en. Som retur kommer der en datareader hvorved man kan oprette x-antal Medarbejder-objecter ved at iterere gennem datareaderen.
4) Ved at basere hele DAL'en på interfaces (IDataReader, IDbCommand, IDbConnectio osv.) kan man gøre DAL'en uafhængig af hvilken datastore der bruges.
Det er da en ide til opdeling som er rimelig tydelig.
Rapporten skal desværre snart afleveres, så der er desværre ikke så meget tid til at lave koden så meget om. Tilbage er der bare at skrive om det og så argumentere for det efter bedste evne :o)
Hvis ikke at søgemaskinen på eksperten sucks, så kunne jeg godt. jeg kan virkelig ikke finde den igen, desværre.. har søgt i 20 minutter og giver op :(
Hm - jeg er vist lidt sent ude. Min Craig larman er også fra 98. Fasndt vi nogensinde ud af, hvad proggie, der skulle bruges til at tegne diverse diagrammer op i. Klassediagrammer etc. Man kan vel snyde med et JAVA ditto, men findes der noget i VS.net til Csharp ?
mach3> jeg har lavet en webapplikation og er nu i gang med at dokumentere den. Er det ikke det omvendte af OOAD ;-)
eksamensprojekt er det dog ikke - det er snarere et midtvejsprojekt :-)
Synes godt om
Ny brugerNybegynder
Din løsning...
Tilladte BB-code-tags: [b]fed[/b] [i]kursiv[/i] [u]understreget[/u] Web- og emailadresser omdannes automatisk til links. Der sættes "nofollow" på alle links.
