-September 2018+
SMTWTFS
2627282930311
2345678
9101112131415
16171819202122
23242526272829
30123456
  • RSS
  • Add To My MSN
  • Add To Windows Live
  • Add To My Yahoo
  • Add To Google

Statistics

  • Entries (1)
  • Comments (0)

Archives


Het ontwerpen van Connectoren 

Wednesday, July 27, 2011 9:34:00 AM

Deze keer wil ik het hebben over connectoren en hiermee bedoel ik een connector die jouw applicatie verbind met een extern systeem (ERP, CMS, Administratief systeem etc.). Vanuit mijn dagelijks werk zie ik dat er voor deze systemen, vaak zelfs niet in een aparte library, een referentie naar een webservice wordt gemaakt. Meestal met gegenereerde proxy klassen, waarna deze direct in de bestaande applicatie worden gebruikt. Meestal nog in combinatie met allerlei businesslogica. Ik noem deze methodiek voor het gemak hier "sterke koppeling(en)".

Als dit beperkt blijft tot een, hooguit twee, externe systemen is dit nog te overzien en kan een sterke koppeling tussen jouw applicatie en deze externe systemen gerechtvaardigd zijn.
Echter in mijn huidige job wordt er naar steeds meer systemen een connectie gemaakt en deze zijn allemaal met sterke koppelingen gemaakt. Onderhoud is hierdoor scheer onmogelijk, omdat dit nog versterkt wordt door allerleid knutsels om deze connectoren aan/uit te kunnen zetten en verweving met de businesslogica. E.e.a. afhankelijk van de licentie die de klant heeft en/of welke ERP(achtig) systeem deze gebruikt.

Om deze redenen heb ik een connector ontwerp gemaakt gebaseerd op de implementatie van Interfaces, waarbij de consumerende applicatie geen kennis nodig heeft van de connector om de koppeling te kunnen maken. Per extern systeem kan een dergelijke connector gemaakt en onderhouden worden. De consumerende applicatie hoeft alleen maar een instantie de interface te creeren en de methode met de gewenste resultaten te verwerken. In de voorbeelden heb ik een domeinmodel gebruikt dat ook door de connectoren wordt (her)gebruikt, zodat er zelfs geen conversies meer nodig zijn in de consumerende applicatie. 

Voordelen op een rijtje

  1. Geen vervuiling van je applicatie door kennis over externe systemen (loose coupling).
    Encapsulation van de connectie logica d.m.v. Interfaces.
  2. Logische scheiding van code per extern systeem en veranderingen in de connector hoeven niet perse in alle consumerende applicaties, of delen hiervan, overgenomen te worden. De connector blijft werken zoals voorheen en de uitbreiding is optioneel.
  3. Scheiding van ontwikkeling binnen je applicatie en van de connectoren. Indien de Interface bepaald is kan de ontwikkeling hiertussen afzonderlijk plaatsvinden.
  4. Door de isolatie van de connector logica kan deze prima op unit en integratie getest worden. Immers het doelsysteem en het bronresultaat zijn bekend, target en expected in unittesten.
  5. Gemakkelijk te hergebruiken voor verschillende applicaties, in principe zouden de connectoren direct verkocht kunnen worden om door andere .Net applicaties geconsumeerd te worden.
  6. Al deze punten zorgen voor een hoge maintainability (onderhoudbaarheid) en reliability (betrouwbaarheid) en maken de eenmalige inspanning van het ontwerp zeker de moeite waard.

Voor degene die interesse heeft in de details, ontwerp en code, verwijs ik naar de volgende skydrive map:

Uiteraard ben ik erg benieuwd naar jullie mening dus als je opmerkingen, review commentaar e.d. hebt laat deze dan als reactie achter op deze blog.

Site Map | Printable View | © 2008 - 2018 LeBroITSolutions | | HTML 5 | CSS