All posts of Jean-Christophe Chalté
-
Entity Framework Code First has introduced many included features that most team projects had to build manually, such as code and database schema synchronisation during the developement lifecycle using initializers (eg. DbMigrations) and data seeding. To use the later, the developer simply has to override the Seed Method of the initializer he has chosen to use. But the developer (or the architect) still has the responsibility to ensure that the seed code is well made, and easily maintainable. With a number of EF entities of dozens or even hundreds of table on most medium sized projects, the developer will have to think of an architecture that can divide the complexity of seeding the whole database. This article will focus on one architecture that can handle the complexity of the seed process without being too hard to use by the developer. As often, simpler is better.
-
This post is the following part of Contract Generation (1/2).
-
In previous post about Model description, we discussed how we could describe webservices using a common XML file that will be used by the tools we will be writing in order to manage them. It is now time to start dealing with all the repetitive tasks and makes your hand dirty. We will start with a basic template to output all contracts in one C# file directly, and we will move to a cleaner solution as tutorials will go.
-
As we have seen in the introduction blog post, managing web services can be a repetitive and error-prone task, as it requires many manual steps from the developer. The only parts where he adds some real value to the project are when:
- He defines what the service do (usually by defining the contract)
- He implements the service.
We have decided that we will develop some tools that help the developer and improve his productivity. These tools will be based on an interface in which the developer can manage his web services (CRUD operations). This interface will need a common “model”, an in-memory representation of his web services. This is what we will focus on this post.
-
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.
-
In the following (and first) serie of posts, I will try to introduce one nifty feature that deserves more recognition than it currently has: text generation using T4 templates. If you are an avid Microsoft developer, you probably have used T4 when manipulating the Entity Framework. But before talking about examples of this feature (which will be described in further articles), let’s start with the basics.