It’s All About the Metadata

Metadata is data about data. Here, it is data that will drive the code generation. This is data describing the code that we want to generate. Quite literally, metadata drives code generation.

Keeping Your Metadata Clean

If your code generation approach relies on being able to regenerate on demand, you must protect your metadata. You want to make sure that it stays current and clean. Without proper care, these two goals may be at odds with each other. We will discuss strategies to help manage this contention. We will also see shortly that there are two types of metadata that we will work with.

Intrinsic Metadata is metadata that we don’t really have to worry about updating. This data stays current without any extra effort on our part. Examples include Reflection, data that the compiler will keep current every time you compile, and the database Data Dictionary which the RDMS will keep current for us. Chapter 7 will focus on Reflection and Chapter 6 will focus on the Data Dictionary

Extrinsic metadata will require more work on our part. This is metadata that we might create specifically for Code Generation or it may already exist to support other parts of the system. The key thing is that we need an external process to update and ensure that it is current and accurate. Examples here are often domain specific and will often dependent greatly on the business needs.

Keep Your Generated Code Clean

If your development process is based on being able to regenerate code on demand, you must also keep the generated code clean. This means making sure that any changes to the code are either incorporated into future regenerations or are protected from being lost during future regenerations.

We have a couple of strategies for ensuring that code changes persist across regenerations. The simplest is updating the metadata used to drive the code generation, but sometimes this is not enough. We also may need to update the template used to generate the code.

For example, we can easily change the code generated for an Entity Framework entity by updating the metadata. Add a column to a table, and the corresponding entity gets a new property. Instead of adding the property, update the metadata first, and let the code generation update the code.

Alternately, we may decide that we want to add an IsVisible property to every defined property for a ViewModel. This will be a relatively straightforward change to the template driving the code generation. Again, we don’t want to make such changes directly to the generated code. Instead, update the template and let code generation update your code.

Tip: The key thing to remember is DO NOT directly change the files generated by the code generation.

Sometimes we may have a “one off” change to make to the generated code. This is a change that does not follow a pattern and may not be reproducible or needed anywhere else. Such changes cannot easily be made or described using metadata or templates. Examples may include calculated fields that are not mapped to the database, or context-specific, custom validation logic.

Even in these scenarios, we don’t want to directly manipulate the code that was generated. This does not mean that we cannot change the code. We cannot change the code in the output file created by the code generation, but thanks to partial classes, we can live with this restriction.

Tip: Always mark generated classes as partial so that the implementation can be spread over multiple files, only one of which will actually be off limits. We are free to add a new file to the class definition and make whatever changes are needed there.

Finding Metadata

An initial challenge when generating code is finding metadata. Fortunately, .NET is all about metadata. We access this metadata through reflection. We will explore reflection further in Chapter 8. For now, we will simply mention that reflection gives us access to all of the data about the types in an assembly.

Reflection

Using reflection, we can load an assembly and search through the types in that assembly. For any type, we can search through its properties, events, and methods. For any method, we can loop through the parameters and examine the return type.

This gives us access to a lot of information. In Chapter 7, we will step through code showing how to access this data, as well as explore some options for using this information to drive code generation.

Data Dictionary

The data dictionary in every database is another great source for metadata. Without any intervention on your part, the Relational Database Management System (RDMS) keeps track of metadata about every table, every column in each table, every stored procedure, and each parameter for these stored procedures, as well as the details for every relationship and constraint in the database. The RDMS keeps track of even more metadata just to keep the database running, but these are the main types of metadata that we will care about for code generation. Databases are very metadata intensive, and the data dictionary is the key to this metadata.

In Chapter 6, we will explore the SQL Server Management Objects (SMO) library, which provides a rich object model for accessing this data and much more.

Code Model

The code model is an API provided by Visual Studio for walking through the code in Visual Studio before it is compiled. It gives us access to the same data that we get through reflection without having to compile to an assembly first.

The code model is a notoriously difficult API to work with, but don’t worry—we will decipher its mysteries, and show how to get data we need to drive code generation.

Chapter 8 will explore the code model further.