Databases Reference
In-Depth Information
The
DataType
enumeration does not define all possible business data types you might
need in your entity models. For instance, the
Region
property of the Employee entity is of
type
string
, a low-level technical type; however, from a business perspective, you could
consider it to have a high-level type
state
, which limits its potential values to a list of
about 50 states and territories used by the U.S. Postal Service. You can indicate this design
in the entity model by applying the
DataTypeAttribute
to the
Region
property and speci-
fying a custom type name instead of a predefined value from the
DataType
enumeration.
Here is an example:
[MetadataType(typeof(Metadata))]
partial class Employee
{
private abstract class Metadata
{
[DataType(“State”)]
public object Region { get; set; }
}
}
NOTE
As you might want to point out, you could also have created an enumerated type to
represent the USPS list of states and territories. For the sake of this example, let's
continue with the assumption that using a string type makes more sense. As you see
shortly, this is not a final design of the
Region
property anyway.
Dynamic Data treats custom data type names as first-class citizens. During field template
lookup, it tries to find a template with the name matching the custom type specified in
the
DataTypeAttribute
and falls back to the physical type only if it does not find the
match. As it happens, a field template called
State_Edit.ascx
was created back in
Chapter 10, which displays a drop-down list and allows users to select a valid state.
Dynamic Data automatically uses it for the
Region
property of the Employee entity based
on the data annotation in the preceding sample code.
FIGURE 11.6
Web page generated by State field template.
