01. marts 2005 - 14:17Der er
8 kommentarer og 1 løsning
Design-spørgsmål - shared DLL vs. 3 x GUI
Here goes:
Jeg har 4 projekter i Visual Studio, 3 små programmer A, B og C, der fungerer som grænseflader for noget funktionalitet, der ligger i en DLL, som de 3 programmer trækker på (en TCP-IP server, der har fælles funktionalitet for alle 3 programmer)
Jeg vil gerne kunne sende beskeder fra min DLL tilbage til grænsefladen, men hvordan fortæller jeg min DLL, hvilken grænseflade den skal sende tilbage til? Jeg har forsøgt følgende:
1. Ændre namespaces, så de er ens for alle 4 projekter - uden held
2. Lavet en public metode i hvert af projekterne A, B og C, der returnerer instansen af min GUI, som jeg så troede, jeg kunne trække ind i min DLL og derved invoke nogle metoder op i GUIen. Også uden held
Jeg er en anelse blank - skal jeg kigge på et bestemt design-pattern eller hvad er næste skridt? Jeg kan regne ud, at løsningen på mit problem er noget runtime-relateret, men jeg har ingen ide om, hvor jeg skal lede for at få info om emnet.
Evt. links er velkomne - skriv for yderligere info :o)
Det er ligegyldigt om de er i samme namespace eller ej. Det er bare en logisk gruppering af kode - og det kan altid løses ved at lave noget passende using.
Lad dine 3 GUI klasser implementere et bestemt interface med de metoder som skal bruges i din common DLL og send this med over i enten constructor eller en register metode til din common DLL (som kun kender interfacet).
Hvis du vil søge efter et pattern, så søg på observer pattern !
en anden mulighed var måske at bruge callbacks? Du kan fra din gui sende en delegate med ned i din dll, som den så sørger for at udføre når gui'en skal opdateres.
Jeg har kigget lidt på Observer-pattern som beskrevet på MSDN og det ser ikke helt tosset ud. Havde også en ide om, at delegates muligvis kunne være en løsning, men vil lige prøve den anden indgangsvinkel først.
:) ja... med den stærke implementering af events i .net kan det som oftest bruges istedet for en decideret Observer/Observable-relation hvor Observable sørger for at kalde en metode i Observer. Der er events meget dejligere at arbejde med, hvor Observer kan abonnere på et event i Observable.
Jeg vender lige 180 grader igen - Vinderen blev alligevel Observerpattern... Jeg rendte ind i problemer med den forrige løsning, så i stedet for at bikse videre og ende i noget slam, der ville være svært at vedligeholde, prøvede jeg for sjov implementeringen af Observerpattern - og voila, 10 minutter, så var jeg kørende :o)
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.
