31. januar 2012 - 11:32Der er
11 kommentarer og 1 løsning
ImplService spørgsmål
Hej,
Jeg har et projekt (privat), som jeg påtænker at gå i gang med. Jeg har i den forbindelse overvejet at lave det både til web og som en client/server løsning.
Nu har jeg så nogle spekulationer i den retning.
Normalt ville jeg lave følgende klasser: DALStoredprocedure klasse (her mine storedprocedures ligger) DAL klasse (her jeg laver Get/Set/Ins/Del) kald/metoder til databasen. ImplService klasse (her jeg laver selve metoder med manipulation af ting jeg henter fra DAL klassen) InterfaceService klassen (her oprettes selve metodenavne med in- og output parametre)
Klasserne DALStoredprocedure, DAL og InterfaceService er ens (såvidt jeg umiddelbart ser det) uanset om jeg laver det til Web eller som en client/server løsning.
Men så kommer vi til ImplService klassen.
Hvis jeg laver den til web, ville jeg lave den som følgende: namespace ImplService { public class Appendixes : IAppendixService { //Metoder her } }
Når det er en Client/servcer løsning gør jeg som følgende: namespace ImplService { public class Appendixes : MarshalByRefObject, IAppendixService { //Metoder her } }
Altså der er en forskel i kaldet mht. MarshalByRefObject
Betyder det så, at jeg skal lave to ImplService og dermed også to forskellige Interface Services. Eller hvordan løser jeg det, så de kan bruge det samme?
Jeg er ikke saa glad for #3. Det er lidt noget roderi. Men med en kommentar i toppen af koden som forklarer situationen kan den maaske godt bruges.
#2 giver lidt ekstra arbejde p.g.a. alle passthrough metoderne som skal skrives. Til gengaeld er modellen god hvis du skal tilfoeje andre transporter saasom .asmx web service, WCF web service, plain socket etc..
#1 har den store fordel at web app og desktop apps kan dele cache i service laget, hvilket tillader meget mere agressiv caching og deraf foelgende bedre performance. Til gengaeld er der saa ogsaa lidt mere kompleksitet i web app.
Arne Sikkert dumt spørgsmål - men har ikke hørt om IFoobarService - er det en webservice? Og ikke mindst - kender du nogle tutorials i opbygningen af IFoobarService?
Janus Jeg kan ikke svare så "nørdsk" som Arne, men det jeg har læst mig frem til, er at det er pænest at adskille tingene, så hvis såfremt, jeg senere skulle finde på at lave anden "klient" i et projekt, så er det nemmere at implementere, hvis jeg har adskilt tingene med et interface. Og ja, jeg kan også se det smarte i det. For et års tid siden lavede jeg et webprojekt, som er helt standalone. Dette projekt, har jeg da overvejet at lave også som en winprojekt. Men kan jo nu se, at jeg skal igennem rigtig meget én gang til, fordi jeg ikke har adskilt tingene.
Mht. Orm, så har jeg bestemt overvejet dette. Jeg kan se rigtig mange fordele. Men har så også her på arbejdet fået et projekt, hvor LLBLGen Pro bliver brugt......og den bliver det bare aldrig, jeg selv personligt kommer til at bruge. Jeg overvejer i stedet NHiberNate, hvor jeg (når jeg får tid) har kig på NHDesigner fra mindescapehg og VisualParadigm.
Det er altid en god idé at adskille tingene, men desværre kan det også medføre unødig kompleksitet og derved både forlænge projektet og endnu værre... hotfixes som udføres "out-of-layer" fordi man ikke lige orker eller måske kan programmere en bestemt funktionalitet i det pågældende layer, derudover kan der hurtigt opstå koderedundans og performanceissues.
At adskille tingene er ikke nødvendigvis at køre en stram n-layer som mange tror, men derimod at udvikle med en langt mere simplificeret tilgang, overholde unit-of-work og opbygge en god domain model.
Jeg vil naturligvis stadig beholde præsentation og service/ domainet, men...
Jeg vil modsat Arne, totalt undlade at fylde mit DAL / repository op med overflødige funktioner når der arbejdes med en ORM. Jeg ville i langt større grad benytte IQueryable og undlade alle de har "dumme" funktioner eks.vis GetPersonById(int id) {....} , men altså blot lade det være tilgængeligt i servicelaget. Funktioner som eks.vis GetSomeFooFromDB(int x, string y) som i bund og grund bare skal hente noget udfra en tabel eller 2 vil jeg slet ikke placere noget sted, men bare udvikle den i domain modellen, ingen grund til noget koderendundans ned til at et repository/ dal.
Mere komplicerede udtræk som måske GetLatestSaleByAreaGroupedByManager, ville jeg måske smide i et repository/ dal, men der skal virkelig være en god grund til det.
Studér begreber som YAGNI og DRY :)
Jeg ved godt min approach er lidt atypisk, men klog af skade.
Der er ingen grund til at tro at skarp lag opdeling skulle give mere redundans. Tvaertimod - naar ting skal vaere et bstemt sted er det langt nemmere at genbruge. DRY er for lag opdeling.
Men YAGNI er naturligvis imod lag opdeling indtil man har brug for det.
Og jeg er helt enig i at "vi bruger altid 3 lag - Pl, BLL og DAL" er en alt for rigid model.
Der er ikke nogen grund til at tilfoeje kompleksitet, hvis man aldrig faar brug for de fordele man faar ved det.
Jeg er dog langtfra nogen YAGNI tilhaenger.
Det er der flere grunde til: * det er normalt meget billigere at lave den forkromede struktur fra start af end at refaktorere senere * det meste kode lever langt laengere end oprindeligt antaget - regn med at koden skal bruges i 10-25 aar - det er totalt umuligt at sige at man ikke faar brug for noget i loebet af saa lang en periode * der er en stor sandsynlighed for at naar systemer vokser senere, saa er der ikke tid til at lav den rigtige refaktorering men at man maa hacke det indtil det er spagetti
Jeg tror nu nok også vi grundliggende er enige, det handler om at komme godt fra start med en fornuftig struktur som kan bære produktet i mange år frem og med mange nye featuretilføjelser.
Jeg er heller ikke 100% tilhænger af YAGNI, jeg nævnte den fordi enhver udvikler bør kende til konceptet og man kan spare sig for meget kompleksitet når man lige træder 2 skridt tilbage, især hvis man skulle være så uheldig at fortabe sig i "nice to have"-features :)
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.
