Web service management using T4 – Introduction and goals
If you want an introduction on what T4 is, please read previous post.
One way to detect where T4 can be interesting is by finding where the developer job starts to become repetitive (and most of the time error-prone). In most of my projects, one of this part was web services (and operations) declaration and management.
Typically, adding a new web service requires to:
- Study what the service is about, and what operations it will expose.
- Add a new interface to one of the project (the WCF contract)
- Add a new method declaration in this project for each operations the service is responsible
- Create all the DTO that will be used by the service, with the right properties
- Create an implementation of that service in the relevant project
- Implement all methods of this service.
- Expose this service from the website, by adding the correct .svc file
- Add the right WCF configuration in the web.config file
- Generate all web service references for each clients
- Generate a client-side data access layer to manage asynchronous calls on each clients
- Comment all those classes and methods
Adding a new operation typcally requires the developer to complete manually almost all those states. Modifying the signature of a web operation requires many change. Renaming or deleting a service or an operation is mostly a manual process.
In all these steps, the developer really creates an added value when:
- he defines what the service is about
- he implements the operations
All other steps are “dumb” steps as they don’t append value to the project. Moreover, most of these manual steps are all error-prone, and as most development teams are “teams”, each part of the team has to understand all of these steps, and follow the same guidelines; otherwise the code will become really hard to maintain.
Most of these steps can be automated in order to avoid all those pitfalls and greatly increase productivity.
At the end this series of post, the developer will have a unique interface where he can manage all his webservices. From this interface, he can create, edit and remove his web services. This interface will take care of all the repetitive tasks (including interfacing the different clients, not necessarily C# though). The developer only has to fill the C# code of his implementation. These tools will be reusable amongst different projects. Unlike proprietary solutions, the developer will have a full control on what functionalities are needed and how those repetitive tasks are done (including how code is generated).