Extracting Metadata - Why Extract Metadata?
(Page 8 of 22 )
Metadata is a key that unlocks many doors. Not only does it play a critical role in CodeDOM, brute-force, and XSLT code generation, but it also plays a similar critical role in many dynamic data/reflection-driven architectures. Even if you code things the old way, line by line, metadata plays a role although you probably don’t think in those terms. When you look at things such as data diagrams and hold that information in your head until you manually incorporate it into your application, your brain extracts metadata. Although it doesn’t stack the metadata up neatly the way XML can, it performs the same kind of translation with metadata you’ll ask templates to perform.
What you create with metadata can be as varied as the metadata sources. You can create any .NET source code, HTML, XML, RTF, stored procedure, or any other text-based file. (See Footnote 9.) This means you can use generation from metadata to perform tasks as varied as creating your database and documentation in addition to producing code. This book focuses on creating .NET source code and stored procedures to select and update data because that’s the common ground where we all work. Many of you will take generation further in a direction specific to your application or environment.
(Footnote 9. Hypertext Markup Language (HTML) is for Web page development. Extensible Markup Language (XML) encapsulates data with metadata defining the contents. You use Rich Text Format (RTF) in a generic word processing format.)
Metadata is also a key step in your development strategy. It’s a bridge between your templates and your data. It’s information that’s ultimately derived from requirements ready to marry templates expressing your architecture. Getting your metadata ready for template development is a significant milestone. Later template development and metadata extraction will be like hand and glove. The template determines what metadata you need; the metadata defines what the template can do. Where you get the data may vary and the contents of the templates will change, but the process of extracting metadata and applying templates remains the same regardless of what you’re building.
Designing Metadata
What does the target metadata look like? It looks like XML, of course, but that doesn’t tell you anything because you can organize XML just about any way you want. The goal is to have the metadata friendly to code generation. This means the following:
- Pushing all possible processing into metadata extraction to maximize reuse
- Having a predictable location for any piece of information independent of how it’s extracted
- Simplifying access even when it means providing redundancy
- Not allowing metadata to become language specific
You want to push as much processing as possible into the extraction step because it supplies an automatic level of reuse. For example, you can do type conversions, such as SQL type names to .NET type names, as part of your meta-data extraction. Each time you extract a particular column type, you may use it ten or more times in templates. Because you’re going to automate things, repeating stuff is okay.
NOTE: Within the XML metadata file, you need a single, predictable location for specific types of data so you can find the data you need when you’re doing code generation. Few of us have organized desks. Most of us can find what we’re looking for without much difficulty despite the chaos around us. But try to explain to a coworker where a particular document is when you’re stuck at home with the flu. Metadata is more like the office supply cabinet than your personal desk. You want to get what you need, and get back to work. So does everyone else working on your project now and in the future. It’s not your desk. The organization schemas I use are a good starting point. Evolve them intelligently. |
Simplifying access sounds like a noble goal, but how do you accomplish it? Imagine doing code generation, and imagine what you might need at a given point. For example, consider writing a class that represents a database table. You need the table name, the column information, the primary key information, child relations, and parent relations. For each relation, you need the specific parent and child keys of that relation. In some organization schemes, including XSD, this is scattered all over the place, which is bad. Use the extra bits and repeat parent and child relations within data elements. This makes it easy to pick up a single node and work with it.
In creating some aspects of metadata, you’ll have to choose between using a .NET Framework or a language-specific element. This will happen with data types and check constraints. For data types, you can use int, System.Int32, or Integer. They all mean the same thing, but only Int32 works with any .NET code. Even if you don’t anticipate language changes, you hope your metadata will have a long life, and who knows how languages will evolve. If you really can’t imagine having code that looks like this:
Imports System
...
Dim j as Int32
or this:
using System
...
Int32 j;
then include both the language-specific and framework name in your metadata.
 This is from Code Generation in Microsoft .NET, by Kathleen Dollard (Apress, ISBN 1590591372). Check it out at your favorite bookstore today. Buy this book now. |
Next: Establishing Your Own XML Design Guidelines >>
More Database Articles
More By Apress Publishing
/ 17 
