Architectuur grote desktop applicatie

[Anoniem: 172123]

Ik ben bezig met een vrij grote desktop applicatie. Met desktop applicatie bedoel ik een client applicatie met user interface.

Nu werkt alles, maar ik heb het gevoel dat de achterliggende architectuur niet perfect is. Ik heb al meerdere keren refactoriteraties gedaan maar ik kom niet tot een architectuur waar ik echt tevreden mee ben. Ik weet dat er geen architectuur is die voor alle desktop applicaties geldt, dus ik zal kort uitwijden over de inhoud van de applicatie die hier relevant is.

• Er lopen verschillende autonome processen in de applicatie op de achtergrond. Dit heb ik goed voor elkaar; het is geïsoleerd in een aparte assembly en de communicatie loopt prima met events;
• Er is veel communicatie met servers, zowel stateful als stateless. Het stateless gedeelte werkt met webservices, en daar horen dus data transfer objects bij. Data access objects blijven op de server;
• Data die uit de server binnenkomt of die anderszins gemaakt wordt (plug-ins, verbindingen, instellingen, etc) hebben een eigen class die properties en relaties heeft voor weergave in de UI (dit zijn dus geen DTOs).

Nu heb ik allemaal prachtige dingen geleerd, gelezen en zelf ondervonden met MVC, maar ik ben er toch wel achter dat MVC vooral van toepassing is op de presentatielaag. Ik kan mijn autonome achtergrondprocessen bijvoorbeeld niet passen in MVC.

Vraag 1: Ik denk dat het derde punt (de data voor de UI) in het model van MVC hoort. Dat was ook het idee. Echter, met puur MVC is het m.i. zo dat alle acties door controllers uitgevoerd worden. Als ik dus in mijn model een class Connection heb die weergegeven wordt door de UI, is het tegen de principes in als ik hier een functie Disconnect() maak, want dat hoort dan in een controller. Heb ik dit juist?

Vraag 2: Ik heb nu een Facade in het UI gedeelte om te reageren op acties van gebruikers. Deze kan bijvoorbeeld forms maken en controllers aanroepen. Ter illustratie: het weergeven van het instellingen venster of het inloggen op de server zijn methods in de Facade. Dit werkt prima, maar is dit logisch?

Vraag 3: Ik heb nu drie controllers: een controller voor de achterliggende processen, een controller voor data en een voor plug-ins. Die achtergrondprocessen kunnen de data beïnvloeden. Als er een verbinding verbreekt of data wijzigt, dan wordt dit door de data controller verwerkt. Deze data controller bevat in feite meerdere collecties van classes zoals ze in de UI weergegeven worden. Dus: als een achtergrondproces een wijziging heeft wordt dit aan de data controller doorgegeven. Deze update het model. Probleem is hierbij dat dit in een andere thread gebeurt dan de main thread, waardoor de user interface indirect geupdate wordt uit een andere thread. Hoe los ik dit op? Moet de data controller synchroniseren met de main thread? Dit is m.i. ook tegen MVC principes in omdat er dan een sterke koppeling komt tussen V en C.

Vraag 4: Als men op een knop drukt in de UI, dan wordt er een method aangeroepen in de facade. So far so good. Maar hoe reageert een UI nou op events? Moet een facade of controllers events bevatten?

Zoals gezegd werkt het nu prima, dus de vraag is niet hoe ik iets werkend moet krijgen. Het gaat me puur om een goede architectuur waar ik verder op kan ontwikkelen en het goed over kan dragen.

Alvast bedankt!

[Niemand_Anders]

Vraag 1: Disconnect hoort wat mij betreft net zoals Connect in Model thuis. Immers de data layer is verantwoordelijk voor de interactie met de database. Ook als de controller niet netjes Disconnect aanroept, moet de verbinding met de database server netjes verbroken worden. In mijn data layers roept de destructor de Disconnect functie en daarna pas Dispose(). Op die manier weet ik zeker dat alle verbindingen (resources) netjes gesloten worden.

Vraag 2:
Een facade kan kan prima gebruikt worden om een service aan te sturen.

vraag 3:
MVC is eigenlijk alleen toepasbaar op interactieve processen zoals een windows form of webpage. Maar MVC is 'slechts' een methode om data (Model), business (Controller) en presentatie (View) gescheiden te houden. In het geval van een achtergrond 'service' houd je dus alleen de controller en model over. Overigens zijn de meeste achtergrond processen wel enigsinds te sturen. Behalve het starten en stoppen van de service, kun je ook custom commands (Integer 128 t/m 255) doorsturen waarmee je wel enige interactie kunt krijgen. Zo hebben al mijn windows services een configuratie scherm (welke eigenlijk alleen maar de app.config wijzigd) en daarna custom command 129 (reload config) doorstuurt.

vraag 4: Een facade is eigenlijk een 'controller' interface. Ofwel een facade stuurt andere (sub) classes aan en deze kunnen wel events bevatten.

DoFactory bevat erg veel uitleg over de verschillende design patters. Hoewel vrijwel alle broncode geschreven is in C#, zijn deze vrij eenvoudig om te zetten naar Java, PHP of C++.

[Anoniem: 172123]

Niemand_Anders schreef op dinsdag 13 mei 2008 @ 11:35:
Vraag 1: Disconnect hoort wat mij betreft net zoals Connect in Model thuis. Immers de data layer is verantwoordelijk voor de interactie met de database. Ook als de controller niet netjes Disconnect aanroept, moet de verbinding met de database server netjes verbroken worden. In mijn data layers roept de destructor de Disconnect functie en daarna pas Dispose(). Op die manier weet ik zeker dat alle verbindingen (resources) netjes gesloten worden.

Ja, dat is ook het idee erachter. Bovendien vind ik het logischer om functionaliteit in de betreffende class te houden. Echter, met puur MVC leek mij in eerste instantie dat het model echt pure data is. Dus niks anders dan getters en setters. Is het met methods in het model ook de bedoeling om vanuit de user interface direct het model aan te roepen en de controller te omzeilen? Zo niet, dan krijg je een heleboel methods met één regel in de controllers (of facade), maar het is wel consistent. Dit mag klinken als gemierenneuk, maar ik vind consistentie wel een van de belangrijkste dingen in software architectuur.

Niemand_Anders schreef op dinsdag 13 mei 2008 @ 11:35:
vraag 3:
MVC is eigenlijk alleen toepasbaar op interactieve processen zoals een windows form of webpage. Maar MVC is 'slechts' een methode om data (Model), business (Controller) en presentatie (View) gescheiden te houden. In het geval van een achtergrond 'service' houd je dus alleen de controller en model over. Overigens zijn de meeste achtergrond processen wel enigsinds te sturen. Behalve het starten en stoppen van de service, kun je ook custom commands (Integer 128 t/m 255) doorsturen waarmee je wel enige interactie kunt krijgen. Zo hebben al mijn windows services een configuratie scherm (welke eigenlijk alleen maar de app.config wijzigd) en daarna custom command 129 (reload config) doorstuurt.

Ja, zo heb ik andere projecten ook en dat houdt dingen duidelijk. Echter, in deze applicatie zijn de achtergrondprocessen in de vorm van threads in de client applicatie. Deze kunnen bijvoorbeeld asynchroon updates voor het model krijgen van de server, die vervolgens in de user interface getoverd worden. Nu moet de user interface door de main thread geupdate worden, dus krijg je een synchronisatie probleem. De user interface is rechtstreeks bound aan het model, dus ik vrees dat de controller moet synchroniseren met de user interface. Is dit gangbaar of is hier een betere methode voor?

Niemand_Anders schreef op dinsdag 13 mei 2008 @ 11:35:
DoFactory bevat erg veel uitleg over de verschillende design patters. Hoewel vrijwel alle broncode geschreven is in C#, zijn deze vrij eenvoudig om te zetten naar Java, PHP of C++.

Ik heb de design patterns wel redelijk op een rijtje dankzij het boek Applying UML and Patterns van Craig Larman. Dit boek en ook die site die je noemt behandelen design patterns maar zaken als hoe om te gaan met achtergrondprocessen kan ik niet terugvinden. In ieder geval bedankt voor de link!

[Alarmnummer]

Anoniem: 172123 schreef op dinsdag 13 mei 2008 @ 18:06:
[...]

Ja, dat is ook het idee erachter. Bovendien vind ik het logischer om functionaliteit in de betreffende class te houden. Echter, met puur MVC leek mij in eerste instantie dat het model echt pure data is. Dus niks anders dan getters en setters.

Dat hoeft niet zo te zijn. Onder Model versta ik dus ook je business laag: de functies die je applicatie moet uitvoeren om iets voor de business te kunnen betekenen, bv hireEmployee, sendMailToFiredEmployees etc.

Is het met methods in het model ook de bedoeling om vanuit de user interface direct het model aan te roepen en de controller te omzeilen?

Vanuit je GUI -> Controller -> Model. Maar vaak zit de controller in de UI geintegreerd. Je zou bv een eventlistener van je UI kunnen zien als de controller.

Vaak kan je zelfs nog onderscheid maken tussen View Models en echte Model. De View Models (bv een TableModel of een ListModel) is een adapter op je echte Model, zodat de laatste gebruikt kan worden binnen een view. De View Model zorgt dus voor de vertaling (adapts) van je Model naar iets dat binnen een UI component op het scherm getoont kan worden.

Ik zou trouwens er goed voor zorgen dat je Model (je service laag voornamelijk) alle business/technische logica bevat. De Controller moet eigelijk vrij dom zijn (niet veel meer dan aanroep naar je service laag, updaten scherm, error meldingen etc).

Echter, in deze applicatie zijn de achtergrondprocessen in de vorm van threads in de client applicatie. Deze kunnen bijvoorbeeld asynchroon updates voor het model krijgen van de server, die vervolgens in de user interface getoverd worden.

Je moet sowieso enorm gaan oppassen met concurrency problemen. Als je je objecten gaat delen tussen je view en achterliggende processen, dan heb je kans op allerlei narigheid zoals race problemen, deadlocks, visibility problemen etc etc.

Oplossing hiervoor is erg applicatie specifiek, dus zal ik hier ook niet al te veel op in gaan. Je zou een threadsafe snapshot functie kunnen maken, en de view deze snapshot laten renderen. In de achterliggend proces stuur je zo nu en dan een soort update event waar je View Model naar gaat luisteren en zichzelf kan updaten (via die snapshot). Je zou ook periodiek de View kunnen updaten (eventueel optimilisatie door bij te houden wat de actuele versie is en de snapshot versie die in de view staat).

Nu moet de user interface door de main thread geupdate worden, dus krijg je een synchronisatie probleem. De user interface is rechtstreeks bound aan het model, dus ik vrees dat de controller moet synchroniseren met de user interface. Is dit gangbaar of is hier een betere methode voor?

Er zijn zeker wel oplossingen. Synchronisatie kan heel complex zijn en synchronisatie in je geheugen is nog complexer. Een mogelijk oplossing zou zijn: laat je asynchrone processen lekker updaten naar een database. En laat je UI lezen vanuit database. Moderne databases gebruiken allerlei technieken om lock contention te verminderen of zelfs volledig te voorkomen.

Ik schrijf alleen serverside apps en de database is voor de meeste applicaties meer dan voldoende om informatie te delen tussen verschillende processen.

Ik heb de design patterns wel redelijk op een rijtje dankzij het boek Applying UML and Patterns van Craig Larman. Dit boek en ook die site die je noemt behandelen design patterns maar zaken als hoe om te gaan met achtergrondprocessen kan ik niet terugvinden. In ieder geval bedankt voor de link!

Ik zou zeker kijken naar "Patterns Of Software Architecture". Hier staat het een en ander in over service lagen, presentatie laag, MVC, concurrency etc etc. Verder is de POSA reeks ook zeer informatie. Als je met Java bezig bent zou je ook zeker kunnen kijken naar Java Concurrency In Practice.

[ Voor 9% gewijzigd door Alarmnummer op 14-05-2008 14:11 ]

[Niemand_Anders]

Allereest vind ik het connecten en disconnecten van een database geen 'functionaliteit' en naar mijn mening dienen deze methodes private te zijn.

Business hoort zeker niet thuis in de data laag (Model). Een methode als sendMailToFiredEmployees heeft niets van doen met de database interactie. Wel kan de Employees model een methode 'IEnumerate<Employee> GetEmployees(EmployeeState state)' hebben om op een dergelijke manier alsnog de ontslagen medewerkers (EmployeeState.Fired) op te vragen. De model behoort alleen verantwoordelijk te zijn voor het ophalen en opslaan van informatie (data).

Functionaliteit voor het verwerken van die informatie behoort in de business layer thuis. Een controller (facade) behoort zelf weinig code te bevatten. Wij houden aan dat een facade methode alleen classes mag aanmaken en daarna de methodes kan aanroepen. De enigste uitzondering daarop is dat als een business methode data terug geeft (de controller zelf heeft geen database toegang, wanyt de informatie kan net zo eenvoudig uit een XML document komen) welke bewaard dient te worden voor de presentatie laag (view).

Overigens houden wij gui --> controller --> business --> data aan. gui en controller zijn vaak verwezen in de form van een windows form of webpage.

Wat betreft concurrency .NET heeft voldoende mogelijkheden om thread the synchoniseren. Er zijn al meerdere threads geweest over threads en winforms, zoeken op ISynchornizeInvoke geeft daarop de antwoorden.

Overigens een flinke rij methodes in je controller is niet altijd een slechts iets. Het betekend namelijk dat alle functionaliteit is los getrokken. als een bepaalde groep methodes vaker aangeroepen dient te worden, dan kun je overwegen om een helper class te maken welke meerdere acties combineert.

Als dit de eerste versie van de applicatie wordt, dan is het verstandig om nog niet te veel wrapper classes en methode te maken. In de ideale wereld wijzigen de requirements niet, maar ik moet het eerste project nog meemaken waarbij tijdens development geen wijzigingen zijn doorgevoerd. Bij opdrachtgevers gaat de applicatie pas 'leven' als met development wordt begonnen en op basis van tussentijdse iteraties kunnen zij beter uitleggen wat zij precies willen. Voordat wij een complete applicatie straat opzetten, maken wij meestal eerst een proof of concept (web)applicatie met zeer beperkte functionaliteit, maar wel met de gewenste schermen.

[Alarmnummer]

Niemand_Anders schreef op donderdag 15 mei 2008 @ 09:04:
Allereest vind ik het connecten en disconnecten van een database geen 'functionaliteit' en naar mijn mening dienen deze methodes private te zijn.

Het is geen business functionaliteit. Persoonlijk vul ik de connectie pool bij het opstarten/afsluiten van een systeem. Maar op de pool en op de connectie zitten zeker wel public methods. Alleen deze methods zullen nooit aan door de Service Layer ge-exposed worden. Ik werk zelf alleen nog maar met DI en dan heb je hier sowieso veel minder last van.

Business hoort zeker niet thuis in de data laag (Model). Een methode als sendMailToFiredEmployees heeft niets van doen met de database interactie.

Volgens mij zitten we hier vast op een definitie kwestie. Ik zou zeggen: pak Patterns of Enterprse Application Architecture er bij. .NET gebruikt trouwens zijn eigen bakje met terminologie..

PS: Domain objecten zonder logica is vaak een anti pattern: anemic domain model. Persoonlijk geef ik de voorkeur om mijn domain objecten niet te rijk en nie tte dom te maken. En alleen de Service Layer en de domain layer horen methodes op de domain model aan te roepen.

Wat betreft concurrency .NET heeft voldoende mogelijkheden om thread the synchoniseren. Er zijn al meerdere threads geweest over threads en winforms, zoeken op ISynchornizeInvoke geeft daarop de antwoorden.

De Java api mbt concurrency is nog veel krachtiger dan die van c# en ik zou het daar al niet mee willen doen. Concurrency control kun je op 3 manieren oplossen:
- isolation
- immutability
- synchronizatie

De laatste moet je zoveel mogelijk zien te voorkomen. Ik schrijf al heel wat jaartjes zo nu en dan een regeltje concurrent code en ik denk dat ik wel weet waar ik over praat.

[ Voor 24% gewijzigd door Alarmnummer op 15-05-2008 09:36 ]

[.oisyn]

Alarmnummer schreef op donderdag 15 mei 2008 @ 09:19:
De laatste moet je zoveel mogelijk zien te voorkomen. Ik schrijf al heel wat jaartjes zo nu en dan een regeltje concurrent code en ik denk dat ik wel weet waar ik over praat.

Hoe zit het trouwens met lockless 'synchronisatie' in Java? Heb je zeg maar equivalenten van de atomic compare-exchange instructies e.d.? Of lockless containers?

[Anoniem: 172123]

Niemand_Anders schreef op donderdag 15 mei 2008 @ 09:04:
Allereest vind ik het connecten en disconnecten van een database geen 'functionaliteit' en naar mijn mening dienen deze methodes private te zijn.

Mee eens. Het ging in dit geval ook niet om een database verbinding maar om een verbinding met een tcp server, die als databron fungeert en events afvuurt.

Business hoort zeker niet thuis in de data laag (Model).

Dit soort teksten klinken heel logisch, maar wat dit nou concreet betekent is mij niet duidelijk en is de reden geweest voor dit topic. Wat zijn "Business" en "Domain" nou concreet in broncode? Hoe zien dit soort classes eruit? Voor elke soort "Business" een singleton met logica? Waar werkt die "Business" direct mee, met je data uit het model? Wat zijn de naming conventions voor .NET?

De model behoort alleen verantwoordelijk te zijn voor het ophalen en opslaan van informatie (data).

Kun je hier "model" nader definieren? Moet ik onder model dus ook collections verstaan die de data ophalen en opslaan m.b.v. webservices? Vallen hier ook de classes onder die de daadwerkelijke data bevatten? Is het de bedoeling dat het model rechtstreeks in de UI zichtbaar is? Dus: is datasources binden aan collecties in het model geldig, of hoort dat op een andere laag?

Overigens houden wij gui --> controller --> business --> data aan. gui en controller zijn vaak verwezen in de form van een windows form of webpage.

Dat is helder. Echter, nu de andere kant op. Er is een tcp verbinding met de server en de server stuurt een update. Deze nieuwe data komt binnen in de handler van de tcp client. Waar gaat het nu concreet langs naar de user interface?

Wat betreft concurrency .NET heeft voldoende mogelijkheden om thread the synchoniseren. Er zijn al meerdere threads geweest over threads en winforms, zoeken op ISynchornizeInvoke geeft daarop de antwoorden.

Dat is geen probleem, mijn applicatie werkt perfect en synchronisatie wordt strikt handgehaafd. Of het echter netjes is, is de reden van dit topic. Mijn vraag hierover blijft wélke layer moet synchroniseren met de UI om wijzigingen door threads te verwerken. Die interface is er voor bedoeld om buiten de UI layer toch te synchroniseren met de main thread wat de vraag doet rijsen in welke layer dit dan wel moet gebeuren. Ik gok "Business" als ik wist wat het precies was

Bedankt voor jullie bijdragen!

[whoami]

Anoniem: 172123 schreef op donderdag 15 mei 2008 @ 19:29:
[...]

Dit soort teksten klinken heel logisch, maar wat dit nou concreet betekent is mij niet duidelijk en is de reden geweest voor dit topic. Wat zijn "Business" en "Domain" nou concreet in broncode? Hoe zien dit soort classes eruit? Voor elke soort "Business" een singleton met logica? Waar werkt die "Business" direct mee, met je data uit het model? Wat zijn de naming conventions voor .NET?

Mja, wat betekent dit concreet.... Dat kan voor iedereen een beetje anders zijn.
Naming conventions hiervoor zijn niet specifiek voor .NET imho; als je over Domain Driven Design praat, gelden die namen voor .NET, voor Java, etc...

In DDD is je 'Domain' een modellering van de 'business' waarvoor je problemen probeert op te lossen. Je 'domain' bevat dus een aantal classes / structs .... Deze entiteiten kunnen entities zijn, value types, repositories, specifications....
Entiteiten kunnen dan weer gegroepeerd worden in 'aggregate roots'.

Een entity kan bv een 'Customer' class zijn. Een value type kan bv een 'Adress' zijn. Een andere entity kan een Order zijn.
De 'aggregate root' Customer kan bv bestaan uit een Customer + zijn Adres + een collectie van Orders.

Voor iedere aggregate root heb je een Repository. Die repository kan worden beschouwd als een soort collectie waar je tegen praat. Je kan in bovenstaand voorbeeld dus ook een CustomerRepository hebben. Die repository abstraheert de manier van het ophalen & populaten en wegschrijven van Customers. (Die repository kan intern bv NHibernate gaan gebruiken om dit te verwezenlijken, maar diegene die die repository gebruikt, hoeft dat eigenlijk niet te weten (in een ideal wereld ~ maar dat is imho niet mogelijk)).

Als je niet het DDD stramien volgt, kan bovenstaand verhaal er eigenlijk heel anders uitzien. (Entity-classes bv die gewoon data bevatten, en geen logica, en voor iedere entity een Manager class die de logica bevat die op entiteiten kunnen uitgevoerd worden).

Kun je hier "model" nader definieren? Moet ik onder model dus ook collections verstaan die de data ophalen en opslaan m.b.v. webservices? Vallen hier ook de classes onder die de daadwerkelijke data bevatten? Is het de bedoeling dat het model rechtstreeks in de UI zichtbaar is? Dus: is datasources binden aan collecties in het model geldig, of hoort dat op een andere laag?

Ik denk dat iedereen hier zo z'n eigen 'waarheid' voor heeft.
De ene gaat zeggen: domain-classes horen perfect thuis in de UI; anderen gaan dan weer beweren dat dit niet zo is, en dat je je domain class moet mappen naar een class die in de UI kan gebruikt worden.
Voorlopig zie ik nog het nut niet in om nog eens een extra laag (extra complexiteit) te gaan introduceren om 'aparte' UI objecten te gaan maken.

[Alarmnummer]

.oisyn schreef op donderdag 15 mei 2008 @ 14:38:
[...]

Hoe zit het trouwens met lockless 'synchronisatie' in Java? Heb je zeg maar equivalenten van de atomic compare-exchange instructies e.d.?

Die heb je, alhoewel het wel afhankelijk is van de hardware. In java 5 is oa de AtomicInteger toegevoegd, voor mee info zie de volgende link. Als de hardware support heeft voor een compare/set dan kan je van deze functionaliteit gebruik maken in Java.

Of lockless containers?

Er zijn in Java 5 een aantal toegevoegd zoals de CopyOnWriteArrayList maar er zijn wel meer. Er zijn geloof ik ook nog een aantal opensource projecten die claimen beter presterende versies te hebben.

Ik neem aan dat je bekend bent met Intel Thread Building Blocks: Java 7 krijgt een oplossing die er wel erg veel op lijkt: Fork/Join Framework. Handig voor fine grained parallellisme.

[ Voor 14% gewijzigd door Alarmnummer op 15-05-2008 21:30 ]

[NetForce1]

.oisyn schreef op donderdag 15 mei 2008 @ 14:38:
[...]

Hoe zit het trouwens met lockless 'synchronisatie' in Java? Heb je zeg maar equivalenten van de atomic compare-exchange instructies e.d.? Of lockless containers?

Er zijn sinds java 5 Atomic wrappers beschikbaar voor de primitive types: java.util.concurrent.atomic. Volledig lockless containers zijn er volgens mij nog niet, er is echter al wel bijv. een ConcurrentHashMap, een thread-safe hashmap waarbij retrieval operaties geen locks gebruiken; en een CopyOnWriteArrayList, die een kopie van de interne structuur maakt waarop iterators opereren. Zie voor meer van zulke collecties: java.util.concurrent.

edit:
Als je eerst nog even wat googled voordat je je post submit ben je dus te laat...

[ Voor 5% gewijzigd door NetForce1 op 15-05-2008 21:38 ]