Databases Reference
In-Depth Information
[MetadataType(typeof(Metadata))]
partial class Employee
{
private abstract class Metadata
{
[EnumDataType(typeof(EmployeeType))]
public object EmployeeType { get; set; }
}
}
As you recall from Chapter 3, Dynamic Data automatically uses the Enumeration field
templates for all properties that have the EnumDataTypeAttribute applied. In Edit mode,
the enum items are displayed in a DropDownList control that looks identical to the drop-
down list produced by the foreign key template.
There is a wide gray area between these two extremes, and you will often need to make a
judgment call on whether a particular property should be an enum or a foreign key. On
one hand, using a lookup table and a foreign key is more flexible—you could add new
values without recompiling the application—and implementing reports at the database
level is easier. On the other hand, using enum properties is much simpler, especially when
you need to have business rules attached to different values.
When in doubt, it is best to start with the simplest solution and change it when you have
a better understanding of the business domain. With this in mind, start with an enum
because this approach reduces the number of entities and relationships in your entity
model as well as the number of tables and foreign keys in your database. It also simplifies
the application code because there is no need to load lookup values from a table or define
special constants. Later, if you discover that business users will want to add new values to
the list regularly , you can create a lookup entity and introduce a foreign key then.
Extending the Enumeration Field Templates
Unfortunately, Dynamic Data web applications do not support display name annotations
for enum items out of the box. For instance, if your enum items need to have compound
names, such as PartTime , the built-in Enumeration and Enumeration_Edit field templates
display the internal names to the users. Obviously, this looks unprofessional, and you
might be tempted to convert the enum property to a foreign key and introduce a lookup
table just to store the display names. Luckily, it is easy to solve this problem by extending
the built-in templates and taking advantage of the data annotation attributes. This is a
small, one-time investment of effort that will provide ongoing savings in cost and
complexity over the lifetime of your application.
To specify display names for enum items, you can either create a new or reuse an existing
data annotation attribute. As it turns out, the DisplayAttribute can be applied not only
to entity properties, but to enum items as well. The following code shows how to modify
the definition of the EmployeeType enum to specify display names for all its values:
 
Search WWH ::




Custom Search