Developing maintainable 2E applications takes thought before writing any action diagram code or even before creating fields. One of the great features of Synon is the ability to create fields by referencing other fields. Once a field is referenced, all fields that reference the base field take on the attributes of the base field. The concept is easy. Let’s see how using this concept can help make more maintainable applications.
How to use Domain fields effectively:
- Plan ahead and create many of the domain fields.
- Use a specific identifier for the domain fields.
- If you create a file and a domain field does not exist for the new field, create the new domain field first.
- Make sure all developers follow the standards.
It is important to plan ahead when using referenced fields as domain fields. The benefits you receive for this planning will last for years if properly maintained. A great benefit is that if you ever move your model to Web Option, you can point a style to a domain field and all of the fields that reference the domain field will pick up the HTML styles of the domain field. Within your model, you can also make mass changes. Any changes to your domain fields will change all the fields that reference it. This is quite powerful.
One of the important items to plan out is the way you will identify the domain fields. Some show use a *, other use D) while others might use a D_. It is good to have the identifier as the first few characters of the field. Then, the name of the field needs to let the developer know what the field is, without having to look at the field properties (ie. D_Text_25). It is very important to pick a standard and stick with it.
Besides the a naming standard, you should create a handful of the primary fields your system will use. Typically, this responsibility will be left with the DBA. If you have one person in your company that does this, the job is much easier. The DBA will also be responsible to create domain fields that do not exist for new database fields. Stick to the plan any time a database field is created it MUST reference a domain field.
If each developer has the ability to act as a DBA, then standards need to be enforced even more strictly. Any time a new database field is created, it MUST reference a domain field.
Many existing models have not followed the practice of using domain fields. Is it worth fixing this? In most cases, not if you have a large model. The job would be too large for the benefits. If you have a fairly small model, then it may be worth creating a plan to update the fields as projects are completed.
Even though it takes planning, up front work and discipline to use Domain fields, years down the road you will either be glad you maintained the practice or you will regret not following the standards. The benefits will outweigh the struggle to maintain the standards.