-December 2018+
SMTWTFS
2526272829301
2345678
9101112131415
16171819202122
23242526272829
303112345
  • RSS
  • Add To My MSN
  • Add To Windows Live
  • Add To My Yahoo
  • Add To Google

Statistics

  • Entries (1)
  • Comments (0)

Archives


The Design of Connectors 

Friday, July 29, 2011 9:48:00 AM

This time I would like to talk about connectors, and with this I mean a connector that connects your application with external systems, i.e. ERP, CMS and other Administrative systems. In my daily work I've encountered numerous examples of connections made by using generated proxy classes, many times even not separated in distinct libraries, and combining these logic directly in their own application logic. Thus creating a strong coupling between their application and external systems, with often reinforcing this effect by even making their own businesslogic depend on the proxy classes code. For the sake of clarity I'll call this methodology "strong coupling".

If this coupling stays reduced to one, at most two external systems, it can be justified to use this methodology. Looking at my current job and the software we sell, this has to make more and more connections with external systems, and until my arrival, all these systems where connected by "strong coupling"'. This makes maintenance a impossible task, because this reinforced by interweaving the on/off switches in existing code in combination with all kinds of businesslogic. Depending on the clients licensing and the kind of External system their using, these switches and businesslogic gets activated.

For this reasons I've made a connector design based on the implementation of Interfaces. So consuming applications don't need to have any knowledge of the external systems of even the used connector to make a connection. Per external system a connector of this kind can be made and maintained. The consuming application only has to create a instance of the Interface, call the correct method and use the result set that will contain the desired object, i.e. collection of objects. In the examples I've provided, I've (re)used the common domainmodel so even conversion aren't necessary. Only drawback on this is that consuming applications of the connector have to use this domainobjects as well.

Advantages in a row:

  1. No pollution of your application by knowledge about external systems (loose coupling).
    Encapsulation of the connection logic by the use of Interfaces and Servicefactory.
  2. Logical separation of the used code per external system and changes in the connector don't have to be necessarily used in all the consuming applications, or parts of them. However the connector will continue to work as before and any expansion is optional.
  3. Seperation of the development in the consuming application and connector is possible, as soon the Interface is defined, the resultsets delivered are known to both parties.
  4. Isolation of the connector logic makes it excellent possible to unit and integration test the connectors. Indeed the target and expected result are known for unittests.
  5. Ease of (re)use for different (.NET) applications, in principal the connectors could be sold as third party components. Every .NET application can easily consume them.
  6. All these points express a high degree of maintainability and reliability  and make the one time effort for designing them more then worth your while.

For those of you interested in the details of design and code just follow the link below to the skydrive map, the design paper is written in Dutch. Sorry guys, I've had no time left to translate it:

 As always I'm very curious to learn your opinions or receive your review comments, so if you have any jus leave them as reaction on this blog or send me a mail @: leo.broos@lebroitsolutions.nl

 

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