Jeg har lavet mig et assembly (dll-fil), som indeholder en række klasser som er public.
Dybt nede i maven på assemblyet har jeg en internal klasse som er ansvarlig for adgangen til databasen. Denne klasse har brug for en connectionstreng. (Denne ændrer sig ikke, når den først er blevet inialiseret)
Da klassen er internal, kan de programmører som bruger mit assembly, ikke tilgå den direkte.
Men de skal kunne angive connectionstrengen. Jeg kan selvfølgelig lade strengen "boble hele vejen ned" fra mine public klasser til den internal klasse, hver gang jeg skal bruge den men dette virker ikke smart.
Mit assembly kender i sagens natur ikke de andre programmørers kode, så jeg kan ikke kalde en af deres klasser, globale variable eller lignende.
Jeg overvejer at lave en public singleton-funktion, som skal "holde" connectionstrengen. Denne kan de andre programmører så kalde fra deres kode, og initialisere. Og jeg kan kalde den fra min internal funktion.
Lyder det fornuftigt, eller er der en bedre måde at sende connectionstrengen ned i maven på mit assembly, ved initialisering af programmet ?
Men jeg synes ikke at det er særlig elegant. Min assembly vil (forhåbentlig/måske) blive brugt af andre programmører i deres programmer. Jeg kender jo ikke deres app.config, og kan ikke bestemme over den.
Jeg mener da at det er pænere at de enkelte programmører selv er ansvarlig for, hvordan connectionstring skal gemmmes i deres kode (app.config, hardcodet,etc). De skal bare kunne "give" den til mig.
Hvis du kender DI/IOC ... så kan du jo lede efter assemblies som implementere.
interface ISearchForConnectionString { int Priority{get;} bool IsValid(); // return true if this has a valid connnectionString string ConnectionString{get;} // return the CS }
og så en runner til overstående som tager den vigtigste ISearchForConnectionString først ... og løber dem igennem indtil den finder en valid.
Overstående er kun ideer ... men at slippe for config ... det er vist aldrig sket før ... :-)
En connection string er ikke en software udvikler ting, men en system administartor ting.
Hvis den paagaeldende database skal flyttes over paa en anden SQLServer p.g.a. diverse kapacitets justeringer, saa er det meget skidt hvis det kraever en software aendring.
At gemme i og hente fra en singleton goer som udgangspunkt koden vanskeligere at laese, da det ikke er indlysende hvor der gemmes og hvor der hentes.
At sende noget ned som argument er normalt at foretraekke.
Singleton til dette formaal boer vaere sidste udvej.
Spørgsmålet er nu ikke så meget "konfigurationsfil eller ej", men mere: "Hvem skal læse konfigurationsfilen ?".
Skal mit assembly læse den, med tilhørende krav til navngivning af parameter m.m ?
Eller skal "slutprogrammøren" læse den og så initialiseret mit assembly med den?
Jeg er enig med jer begge i, at den slags oplysninger jo aldrig skal hardcodes.
Nu var det med configurationsstrengen bare eet eksempel. Men der kunne være mange andre eksempler på, at man ønsker at sætte nogle "assembly globale" variable ved initialisering af assemblyet.
Så spørgsmålet gik ligeså meget på, hvordan man bedst muligt kunne initialisere sådanne variable.
Hvis vi snakker et meget lille system - lad os sige <25 klasser, saa giver det nok mest mening at laese konfig et sted og sende argumenter med over i metode kald.
Hvis vi snakker et realistisk stoerrelse system, saa giver det mening at lade hver komponent/del/lag laese sin egen konfiguration.
Hvis det inden for en enkelt komponent/del/lag er rigtigt mange klasser som skal bruge den konfig (naeppe relevant for connection string), saa kan man overveje en readonly singleton.
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.
