Creating Extensible and Abstract Layer

• Download source code - 8.06 KB

Introduction

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.

Background

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:

1. We need to provide flexibility to change our default functionality (out-of-the-box feature).
2. At the same time, we don't want to break the interfaces so that we don't end up breaking the existing code.

This article gives an overview of how we can solve the above two issues and yet provide a robust extensible and abstract layer.

Extensible and Abstraction

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 Logical Architecture

Service Consumers

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.

Service Façade

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

Services are at the granular level and perform the actual logic of a task or activity or a business logic, etc.

Class Diagram

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.

Pros and Cons

Pros

Following are the advantages of this methodology that I am aware of:

• Consistent end point from the service provider and consumer point of view
• Extensible, the services can be used as is, default functionality can be overridden, and new services can be plugged in without affecting the façade and consumer
• Abstraction, the consumer is totally not aware of internal implementations of the Service façade, service, service execution, etc.
• Ability to perform authentication, authorization logic in a single place
• Ability to route messages to a different service based on pre-built logic, custom logic, etc.
• Ability to perform cross cut concerns like tracing, instrumentation, etc. in a single place instead of in all services and all over the framework
• Easy maintenance of the code

Cons

Following are the pitfalls of this methodology that I am aware of:

• Over a period of time, the Service façade may become bulky handling too many services

About the Sample Program

The sample program contains two C# projects:

• ExtensibleAbstractLayer - class library project
• ClientApp1 – console client application

How It Works

• The console client application takes input as command line arguments
• Pass servicename and servicedata as arguments
• servicename should be the name of the class (service)
• servicedata should be input that the service expects
• When “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!

History

• 18^th February, 2008: Initial post