Extracting Metadata - Using Skip Attributes
(Page 21 of 22 )
One of the common things I hear when I talk to people who have experimented with code generation is that they found not everything should be treated the same way during code generation. Often, certain tables, columns, stored procedures, and so on should be skipped during generation.
You may be tempted to have a narrow, easy solution that one way or another marks metadata items to be skipped. That could just mean adding a Skip attribute to appropriate nodes. That doesn’t work because skipping often depends on the specific context. For example, in a stateful Windows.Forms application, exposing the TimeStamp is just confusing to later programmers, but the value may be passed to the browser and back in a stateless data flow pattern in ASP.NET. Allowing your metadata to become dependent on context greatly diminishes the value of metadata as an independent unit of information about your application. So I encourage you to develop a small set of attributes that specify the purpose of the category and avoid the Skip attribute altogether.
Table 2-5 gives you some ideas; I doubt you’ll want to use all of these, but you can select the ones that make sense for your project.
Table 2-5. Suggested Attributes to Manage Skipping Items During Code Generation
ATTRIBUTE | PURPOSE |
Obsolete | No longer used by any operations |
Private | Not exposed by objects in any context |
StatefulPrivate | Only exposed in a stateful environment |
StatelessPrivate | Only exposed in a stateless environment |
Large | Ignored for tasks that don’t use large objects such as images |
ReadOnly | Lets you provide a different class for read-only tables |
ReportsOnly | Allows you to provide a different class design for reports |
TIP: Don’t use generic skip attributes, but instead categorize elements by adding extra attributes and allow templates to skip as appropriate.
Using an XSD
Freeform metadata isn’t really a free-for-all. You don’t have a lot of flexibility in the structure because the merge process and code output will rely on the specific structure you create. XSD is the perfect tool for defining the structure, or schema, of your freeform metadata. This allows you to validate your XML before you use it and makes editing easier because Visual Studio .NET uses XSDs for IntelliSense, autocompletion, and warnings from the background compiler.
Validation is especially important when you’re using XPath, which you’ll use in all three types of code generation. As you’ll see in the Appendix A, XSLT trusts you completely and will raise no errors if something is missing, misspelled, in the wrong place, and so on. Important information might fail to be used. You can alleviate this problem by using XSD to validate any manually entered or edited data.
NOTE: Hooking up XSDs for use by Visual Studio is covered in Appendix A. You can infer an XSD from an XML file using XSD.EXE directly or right-clicking the XML file in Visual Studio and clicking Create Schema. (See Footnote 13.) You can build a master XML file that contains all the elements and attributes you plan to use as a basis for your schema inference, or you can create a schema off the most complete file you happen to have and maintain the XSD by hand. If you find the XSD format intimidating, the approach of inferring your XSD from a master XML file works well. Just don’t use both approaches because you’ll wreck the edited XSD. |
(Footnote 13. If your XML document runs into problems with the XSD.EXE generator, you might want to download the InferSchema tool from GotDotNet.com.)
 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: Merging Metadata >>
More Database Articles
More By Apress Publishing
/ 18 
