Details determine success or failure: ing Enumeration

I have heard that some people are interested in such a tool: getting the ing object information from the database metadata. I really doubt the value of this tool. It is very easy to obtain metadata information from the database, including the name, type (including some variable length types), whether it can be empty, primary key and foreign key reference (to obtain the relationship ). However, people with modeling experience basically know that this information is far from enough, because metadata also has metadata, there are some relationships that cannot be expressed through the definition of database metadata (such as self-reference), and some are incomplete expressions. For example, each Column has a Caption in addition to the Column name (So DataColumn in the able has both ColumnName and Caption attributes). The functions of these two attributes are different, column names are used for Schema definitions in databases, while Caption is basically used for domain definitions (well-designed MS Access can get Caption). In addition, their character sets (some databases require only ASCII code, in addition, the naming rules are the same as those of labels, although ms SQL Server is loose in this respect) and features (some keywords cannot be used for Column name definition) are not exactly the same. Therefore, they cannot replace each other. The second is that the metadata specification of the database is completely different from the object-oriented metadata specification. In many cases, the Table name cannot be directly used as the Class name or Column name or the Class Property name. T_Customer is not like a Class name; f_CustomerName is not like a Property name. Therefore, it is not unreasonable for me to directly generate the source code of the Entity objects at the business layer from the database structure.

Similarly, when you map the database metadata model to the domain metadata model, it is necessary to map enumeration to the domain metadata model. For example, many people define gender as follows:

Public enum Gender
{
Male,
Female
}

When the property is of the Gender type and mapped to PropertyGrid, a drop-down list is displayed, including Male and Female. If you are in an English country, there is no problem. But it is very annoying in Chinese. Therefore, you can define it as follows:

[MappedEnum (typeof (int), "gender", false)]
Public enum Gender
{
[MappedEnumEntry (0, "male", false)]
Male,
[MappedEnumEntry (1, "female", false)]
Female
}

This is simple. You can modify the Gender type editor so that PropertyGrid can recognize the MappedEnumAttribute and MappedEnumEntryAttribute tags and list the items "male" and "female.

Someone has noticed that in the MappedEnum tag, the first parameter is the enumeration base type (in fact, it is the base type stored in the database, and can support int, bool, string, and char, the base type in enum is always System. int32); the second parameter is the corresponding Caption; the third parameter is an optional control parameter of the bool type. When the third parameter is true, you can obtain the resource from the assembly where the type is located and find the resource string named Caption to replace the Caption at runtime. A very simple definition of optional parameters solves the problem of multi-language.

Of course, MappedEnumEntry can be automatically combined into a set type like FlagsAttribute for multiple dictionary items.

Enumeration is a very important element in the field. Therefore, since the first version of Kanas.net in 2003, enumeration ing is supported.

Obviously, the entity defined as Gender type in the domain object has the opportunity to transparently store it in the database according to the enumeration definition. During Coding, the corresponding identifier can be used directly, in the UI Layer, you can also display the appropriate content as expected according to the customer's requirements. Everything is step-by-step.

However, in actual project practice, there are too few enumerations that are poor and will never change like gender or week. More are enumeration dictionaries that can be changed and constantly enriched. I believe more people have encountered similar situations. Almost everyone defines a table for each enumerated dictionary. I have seen an international industrial software. The enumerated dictionary occupies almost half of the total number of tables, because these items need to be classified for statistics as keywords.

The enumerated dictionary has three commonalities. The first is Business independence. No matter where it is referenced, there is no interaction between them. Once the enumerated dictionary item is changed, it must be caused by the change of the enumerated item itself, and there is no relationship with the quoter. The second is relative stability, which does not need to be changed frequently in most cases. The third is sharing. References may occur in multiple attributes of the same object. These commonalities determine that some common and abstract methods may be used for processing.

My previous project practices adopted a single table:

There are two domain multiplexing:

Category is a self-reference. When the value is zero, it indicates the category of the behavior. If the value is non-zero, it indicates the category of the behavior. If fixed is set to true, a new item cannot be added to this category. Otherwise, a new item can be added. If this behavior item is used, it indicates that the row cannot be edited. On the one hand, it must be used in the business, and on the other hand it may already be used.

Category cannot be added (in fact, adding category is not logical). There are only two types of operations: add new items and delete obsolete items. You can modify the name and editable status, delete the item, and merge it into other items. The first two items are easy to understand. The last item means that the referenced items can be deleted and the referenced items can be changed to the specified items. For example, one item is 30 ~ 40 years old, and someone mistakenly entered 35 years old, of course, to be merged. I remember that the input I provided to users was very free. You can select items in the list in a ComboBox and manually enter a string, if this string does not exist in this category, a new item is automatically added to this category. Over time, a variety of input appeared. Fortunately, I provided the merge item function to the Administrator in advance, which made him grateful.

This method has always been quite helpful, so an automatic type: Dictionary is added to Kanas. net1.0. Later, I found that this class is too simple to be processed because it is a little complicated. So in subsequent versions, I canceled this class. In fact, different enumerated dictionary types are not as simple as I have designed. Different enumerated dictionaries may have to carry other business attributes. For example, the unit has a Conversion Relationship in addition to the name. one-to-many or many-to-many references may occur between different enumeration classes. However, it is certain that the enumerated dictionary items are different from normal entity types and must be completely different in object relationship ing.