Abstraction and Extensibility are important factors in modern day frameworks. If you are part of any framework team or developing a library that will be used by multiple divisions of your organization or community, you will appreciate what I am talking about.
We don't want to develop a reusable framework library for a particular use case and later find that component not usable or not fitting in another scenario. When developing a framework/library that is targeted to be used by multiple divisions, there are many challenges involved. We should build what the applications would use in a normal scenario to fulfill their business requirement. On the other hand we cannot dictate them to use what we have developed as an out-of-the-box functionality. The gist is most of the teams should be able to use it as an out-of-the-box feature. On a need basis due to dynamic/changing business requirement they should be able to override, extend or plug their own functionality into the framework. When it comes to override the default functionality, we don't want to change the endpoints – i.e. interfaces. Changing interface leads to breaking the endpoints.
So we have two problems at hand:
This article gives an overview of how we can solve the above two issues and yet provide a robust extensible and abstract layer.
Extensible framework allows the consumers to extend the default functionality provided and at the same time, they don't break the existing code. Abstraction provides an opaque layer to the consumer who is not bothered about what’s going on the other end of the world but still be able to accomplish the task that he wishes.
The consumers are the end users or external applications or requests originated from a web service, etc. Consumers are the ones who are interested in accessing a service. They accomplish this by interacting with Service Façade. The consumers will interact with the Service façade using Request-Response objects.
The Service Façade is the layer that shields the consumers from accessing the actual service directly. This layer acts as the entry point and routes the message to the actual service implementation that the consumer would like to call. The service router will intercept the message from the consumers, based on the Request, and routes the call to the actual service.
Services are at the granular level and perform the actual logic of a task or activity or a business logic, etc.
The following diagram shows the class diagram of the solution:
The ServiceFacade, the individual Services implement the IService interface and they communicate in a common language using Request, Response objects. This helps the ServiceFacade to call the service and get the job done.
Following are the advantages of this methodology that I am aware of:
Following are the pitfalls of this methodology that I am aware of:
The sample program contains two C# projects:
ExtensibleAbstractLayer - class library project ClientApp1 – console client application servicename and servicedata as arguments servicename should be the name of the class (service) servicedata should be input that the service expects Base” is passed as servicename and “1” is passed as servicedata, the CustomerBase service will be created and GetCustomerName() method will be called with “1” as argument, the result will be “Robert”.Happy coding!
| You must Sign In to use this message board. | |||||
|
|||||
