2.3 Implementing custom result fields

If you remember, we added two custom fields to the results list that are not declared on the sales order object itself: customer store and customer name. The system would not know where they are sourced from, so it cannot generate code that would retrieve these values. What it does generate though is a set of placeholders in the generated service implementation code, where you can supply your custom code to retrieve these fields. They are marked with TODO comments to let you easily find all such places that need custom implementation.

Before we can provide the custom code, we first need to build our model, which runs all the generators. To do that let's right click on the AdventureWorks.Model project, and select the Build menu option. Next, we will expand the AdventureWorks.Services.Entities project and find the SalesOrderService class that implements our service contract. The ReadListAsync method will have a LINQ query over our entities, where you will see the commented placeholders to implement between the CUSTOM_CODE_START and CUSTOM_CODE_END marker comments.

We will provide the custom implementation for these fields, which reads it from the related CustomerObject as shown below.

You may be wondering if the custom code you have just written, which is mixed in with the generated code, will be erased next time you build the model and regenerate this class. As long as you don't rename the result fields or operation in the model, or change anything in the comments with the corresponding CUSTOM_CODE_START and CUSTOM_CODE_END markers, your custom code should be safe during the next model build. Essentially, the marker’s text is used to find the custom code when the class is regenerated, so you need to make sure it doesn’t change.

If you do need to rename the custom parameters or their operation in the model, make sure you make a copy of your custom implementation, or, better yet, version control your code, so that you could see any differences in the generated code after you regenerate the model. You can also manually update the marker’s text in the comments before renaming to match what it would be after renaming, which will preserve the custom code in between these markers.

Another danger to your custom code could be if you select Clean or Rebuild on the model project, or Clean or Regenerate on the corresponding Service Implementations generator. Any of these options will delete the generated files first, which is okay only if the files have no custom code, and basically make sense only if you have renamed some objects in the model, or plan to change the output path patterns for the generators, and would like to automatically clean up the old generated files and update the projects with new files.

In order to preserve the custom code during clean, please follow the instructions at the top of the generated file, which instruct you to delete a certain line in the header comment. For the service implementations you can also configure that in the model in the config section for the object by setting the preserve-on-clean flag to true on the svc:customize element as follows.

Let's run the application and review the effect of our changes so far. Below is a sample screenshot of what it looks like now.

Notice how our result list has only the columns we specified in the output of the "read list" operation, with the details link on the sales order number, dates showing without a time component, and the customer store and customer name populated as appropriate.

Next: 2.4 Modeling the search criteria >