14. marts 2006 - 17:56Der er
32 kommentarer og 2 løsninger
Interface i forbindelse med business lag ?
Hejsa,
Kort fortalt så laver jeg en factory klasse som sørger for at sende den respektive klasse til mit designlag :
Public Class BusinessFactory Public Shared Function LoadClass(ByVal Type As String) As MitInterface Select Case Type Case "class1" Return New Class1 Case "class2" Return New Class2 Case Else Return Nothing End Select End Function End Class
Mit interface holder så på en række metoder :
Public Interface MitInterface Metode1() As Boolean Metode2() As Boolean Metode3() As Boolean Metode4()As Boolean End Interface
Jeg har så to el. flere klasser :
Friend Class Class1 Implements MitInterface Metode1() As Boolean Metode2() As Boolean End Class
Friend Class Class2 Implements MitInterface Metode3() As Boolean Metode4() As Boolean End Class
Men det duer jo ikke helt da den så brokker sig over at jeg skal have alle 4 metoder med i hver af mine klasser. Hvordan skal jeg gribe det an ?
Så forsvinder ideen jo lidt i min factory klasse der tager sig af at sende den respektive klasse som skal benyttes retur til designlaget jo, da jeg jo kalder metoden i den som "As MitInterface".
En klasse skal overholde det interface den arver fra, det er helt essentielt. Jeg er lidt i tvivl om hvad du prøver at opnå, men hvis du bruger .NET 2.0 kan du jo eventuelt bruge en generisk factory metode. Eller du kan lade LoadClass returnere object eller et fælles interface for alle klasserne. I så fald vil det være nødvendigt med nogle type casts for at nå frem til den rigtige type.
et interface er en bindende kontrakt - man skal implementere alle metoder
man kunne lave et super interface som alle implementerer og saa et antal sub interfaces (som arver fra super interface - hvad mange ikke er klar over er at interfaces kan arve)
men saa skal du downcaste og det er absolut ikke paent (og hele ideen med en factory forsvinder ligesom)
grundliggende skal du kun bruge factory som returnerer interface, hvis de faktisk har det samme interface
hvis det er forskellige interfaces skal du have flere factories
hvis det kun er en lille bitte forskel kan du evt. kave en dummy metode i klasserne som smider en exception - det er heller ike paent, men hvad goer man ikke i en snaever vending
hvis du leder efter et framework til at instantiere vilkaarlige klasser, saa kan du kigge paa SpringFramework.NET (der faar du en factory som du kan kalde med et navn og saa kigger factory i en XML config og laver et objekt til dig)
Hej arne_v, ja det er jo dig der har ledt mig ind på den måde at styrre tingene på, men ville det så ikke blot være letter helt at droppe factory klassen og så blot trække igennem interfacet til den pågældende klasse på tværs af de forskellige lag ?
Slam kode i php kender jeg ikke til men slam kode i alm. asp har til gengæld lavet en del af *GGG*
Men tilbage til emnet, for det første bliver det ret omfattende inden jeg bliver færdig. For det andet skulle det hele gerne gå op i en højere enhed i sidste ende. Mine lag ligger i seperate dll'er Data, Business og Design.
Og det var jo netop det smarte jeg kunne se i at have en factory klasse der loader den klasse jeg nu skal bruge i mit design lag.
Men skal jeg så have en factory klasse til hver af mine klasser ? For det kan jeg tilgengæld ikke se noget smart i ?
arne_v >> Nej, men i de klasser der levere noget fra DAL til BLL og fra BLL til PL, korrekt ? Mine info klasser og deslige andre har jo ikke behovet ;o)
driis >> Gik du helt kold ? havde du ikke et eksempel på det generisk factory i asp.net 2.0 ?
OOP er mest velegnet til ting som er stoerre end det typiske hobby projekt
PHP og klassisk ASP er blevet saa populaere som de er fordi de er saa nemme at bruge til at lave 5 dynamiske web sider med
programmerings paradigmet med at man starter i toppen af filen med <% eller <?php og saa koder derud af med echo eller Response.Write er jo noget enhver kan finde ud af
hvis man vil lave de samme 5 sider med ASP.NET eller JSP tager det 10 gange saa lang tid
50 sider gaar ogsaa
men snakker vi 500 eller 5000 sider saa ender ikke OOP loesningerne ofte med en gang spagetti, hvor man ikke kan finde tingene, duplikerer funktionalitet, naar man retter en fejl saa retter man den kun nogle af stederne etc.etc.
man kan godt lave paene loesninger i PHP og ASP, men mange udviklere har faaet nogle grimme vaner inden de blev gode og fordi det er nemt at komme igang med saa er der ogsaa stor tradition for udviklere uden IT uddannelse
At man ingen it-uddannelse har skal vel ikke danne grundlag for at man ikke kan få/have arbejde inden for programmering/design, eller for den sags skyld kunne lære noget om det.
Og jeg kan da allerede nu se fordelen ved at benytte OOP frem for det jeg tidligere har lavet i alm. asp, det bliver hurtigt uorverskueligt hvor det at arbejde med library og klasser gør tingene væsentligt lettere at have med at gøre.
Lad os antage at mit business lag indeholder 5000 linier kode hvoraf ca 1/5 del bruges i forskellige dele af mit design lag, er det så ikke mest hensigts mæssigt at dele det op i 5 klasser med hver deres factory og interface frem for at skulle kalde en stor klasse hvoraf jeg så kun bruger 1/5 del, eller har det ikke noget at sige ?
Ja, men i mine øjne er det jo væsentligt lettere ikke at skulle vælge imellem en hel række properties og metoder der ikke er relevante til netop den del af design delen jeg arbejder med.
Vi er enige om at brugen af en factory klasse er helt i top til adskillelse af de forskellige lag. Det gør det lettere at redigere uden det får nogen indflydelse på de øvrige lag, men det kan godt være at det er mig der ikke forstår brugen af det da jeg syntes det virker tåbeligt at jeg ikke kan nøjes én klasse da det jo netop ville mindske mængden af kode.
Der hvor jeg tror jeg kludre lidt rundt i det er det med hvad der høre til business laget og hvad der ikke gør.
Selve desing laget er vel egentligt den rene html der genereres ?
Business laget er vel en sammen føjelse af mit code_behind, mine infoklasser og det jeg pt. kalder mit business lag, nemlig en mere eller mindre pass through klasse som blot smidder data igennem til mit datalag ?
Datalaget er der ikke så meget tvivl om det handler om adgang til og fra databasen med diverse metoder.
Kan du ikke prøve at komme med din fortolkning af det ?
business laget er den egentlige kerne logik som er uafhaengigt af om det er en web app eller en win app og uafhaengigt af om det er en SQLServer eller XML filer data opbevares i
den klassiske opdeling er 3 lags: presentation layer business logic layer data access layer
enkelte har en 4 lags opdeling og den kan jeg faktisk bedre lide: presentation layer - user interfacet (.aspx) controller layer - behandlingen af brugerens handlinger (codebehind .cs) business logic layer - kerne logik (service og data klasser) data access layer - (data og hjaelpe klasser)
hvis du bruger 3 lags saa kan du enten lave code behind med kun et enkelt kald til BLL og kalde den for en del af PL eller putte en masse logik i den og kalde den BLL
1. Code behind bruger jeg til validering af de input en bruger levere, check af tomme felter, email, længde osv.
2. Business, hvor jeg har min(e) klasser der sørger for levering af de validerede data til datalaget, her jeg så ca. 30 % metoder som blot sender data direkte igennem med f.eks :
Public Function Create(ByVal objInfo As InfoClass) Dim boolReturn As Boolean = False If objDAL.CreateNew(objInfo) > 0 Then Return True Else Return False End If End Function
Det er der jo ikke meget i ?
3. Min dataklasse med metoder der sørger for levering af data til og fra database
4. Database hjælpe klasse og database.
Jeg betragter databasen som en del af 4. lag da jeg benytter mig af de egenskaber den kan levere så som stored procedures, index, views osv.
Jeg føler bare lidt at jeg bruger for meget tid på de pass through metoder, men du vil sikkert sige at jeg ikke skal bekymre mig så meget om det ;o)
faktisk vil jeg mene at det meste af validering af data hoerer hjemme i business layer og ikke i controller layer
controller leyer er mere omkring flow: bruger har submittet disse data nu kalder jeg business layer med dem i tilfaelde af success skal han videre til denne side i tilfaelde af fejl skal han have samme side igen med foelgende fejl tekst
17/03-2006 20:59:40 >> Det virker også som en ganske fin idé, men med de indbyggede validator kontroller ligger det lige til højrebenet at bruge dem i controler laget :
If Page.IsValid Then '--- kald business laget Else '--- giv brugeren besked om at det ikke var super godt End if
17/03-2006 21:05:55 >> Ja, det er nok fordi jeg ikke har tænkt på det som database tier, men så fik du endnu engang udvidet min horisont, cool ;o)
17/03-2006 21:09:58 >> Ja det er noget tid siden jeg læste den og jeg forstår også godt principperne i det, det er mere det med hvad der skal være i PL og BLL jeg er lidt i tvivl om, men hvis jeg skal udelukkende skal bruge PL til submit og visning af data så skal jeg jo droppe de indbyggede validator kontroller og så skrive mine egne, e..er kan jeg trække i dem min BLL klasse ?
simpel data validering (er det her et tal ? er det her en email adresse ? etc.) som godt kan laves i PL/CL og saa mere substans orientered valideringer (eksisterer konto i databasen ? er slut data senere end start dato ? etc.) som skal ligge i BLL
de foerste skal laves i PL/CL fordi data types skal proppes ind i data klasser inden de sendes til BLL
Ok så er jeg sq på rette vej for det er i reglen den fremgangs måde jeg har benyttet, så det var rart at få det på plads, mange tak for de meget nyttige info.
Jeg fordeler dem oxo derefter, men lidt skal du have ;o)
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.
