Click here to Skip to main content
13,147,182 members (27,267 online)
Click here to Skip to main content
Add your own
alternative version


15 bookmarked
Posted 18 Feb 2008

Creating Extensible and Abstract Layer

, 18 Feb 2008
Rate this:
Please Sign up or sign in to vote.
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.


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:

  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 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:

Click to enlarge

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


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


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:</li />

  • 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!


  • 18th February, 2008: Initial post


This article, along with any associated source code and files, is licensed under The Code Project Open License (CPOL)


About the Author

Niranjan Kumar
Architect Cognizant Technology Solutions
United States United States
Solution Architect working for Cognizant Technology Solutions.

You may also be interested in...


Comments and Discussions

-- There are no messages in this forum --
Permalink | Advertise | Privacy | Terms of Use | Mobile
Web03 | 2.8.170915.1 | Last Updated 18 Feb 2008
Article Copyright 2008 by Niranjan Kumar
Everything else Copyright © CodeProject, 1999-2017
Layout: fixed | fluid