Generating the Implementation

Creating the Solution Structure

The first step in generating the implementation for the services is to create the projects the code will be generated into—this is referred to as the solution structure. You can unfold the solution structure by completing exercise 5 in the Building a Service Hands-on Lab. It is also completely reasonable to want to change this solution structure. You can learn about how to change this solution structure by completing exercises 1 and 2 in the Extensibility Hands-on Lab.

The Project Mapping Table

Project mapping is a technology built into the Service Factory that provides a level of decoupling between the models and the projects they will generate code into. Figure 1 illustrates the relationship between the mapping tables in the ProjectMapping.xml file and the solution structure.

Figure 1
Project mapping tables associate the model elements and the Visual Studio projects

The ProjectMapping.xml file can be created and changed in the following three different ways:

• Automatically
• With a recipe
• Manually

The next sections describe each of these.

Automatically

When you use the Add ASMX/WCF Implementation Projects recipe, all the project mappings are created when the solution structure is unfolded. The name of the mapping table is the same as the name you provide when you create the implementation projects.

With a recipe

If you would rather create each of the projects individually in a solution folder, you can use the Populate Project Mapping Table recipe. This recipe uses the suffix of the project names to associate roles to the projects. The following strings are all of the appropriate suffixes to be used in project names:

• “Host”
• “Client”
• “BusinessLogic”
• “BusinessEntity”
• “DataContract”
• “FaultContract”
• “ServiceContract” *
• “MessageContract”
• “ServiceImplementation”

* The ServiceContract project will automatically be associated with the ServiceContract and MessageContract roles.

Manually

If you have already created projects and now you want to generate code into them using the Service Factory, you will have to make manual changes to the ProjectMapping.xml file. However, because the project mappings are represented in an XML document, the document can be edited in an XML editor (such as the one provided in Visual Studio). The following XML snippet is an example of a project mapping.

  <ProjectMapping 
    ProjectId="069c2efb-5e19-439b-8497-824eee16b42f" 
    ProjectPath="\GeneratedCode" ProjectName="MyServiceContract">
      <Roles>
        <Role Name="ServiceContractRole" />
        <Role Name="MessageContractRole" />
      </Roles>
  </ProjectMapping>

The ProjectName attribute is provided for the sole purpose of manually editing the file. It is not used by the project mapping technology in the Service Factory. This means if a project name changes, it will not automatically be updated in the ProjectMapping.xml file—it must be manually performed, but is not required. The value of the ProjectId attribute is the GUID for the Visual Studio project. You can find this value in the ProjectGuid element inside of the Visual Studio project file.

For more information about the project mapping table, see the “Project Mapping Table” section in the Code Generation Extensions topic.

Code Generation

To generate code from the models, you may do so for single shapes or for the whole model, but the code generation framework does not cross models even if there are dependency relationships established between the models.

This version of the Service Factory is only capable of generating Visual C# code and XML for configuration files. During the development of the Service Factory, we tested the architecture to ensure it can generate Visual Basic .NET by creating a text template for data contracts. This text template is in the Service Factory source code to serve as an example to anyone wanting to create the other Visual Basic .NET text templates.

One of the principals of the Service Factory code generation capability is that the user should never manually change code that was generated. To facilitate this, the Double Derived pattern has been applied to generated classes that will need to be changed. This pattern can be seen in any service implementation class. Exercise 8 in Building a Service Hands-on Lab walks you through the process of extending the service implementation through the use of partial classes and method overloading.