The Case
Against Designer Generation
Dr. Paul
Dorsey
After coauthoring five Oracle Press books, two on Designer, one on Developer, one on data modeling, and one on JDeveloper, I have arrived at the following position:
· I don’t currently generate any forms and reports from Designer.
· I am not likely to generate forms and reports from Designer in the future.
· Generating forms and reports from Designer is not a sound application development practice.
There is often confusion about exactly what is meant by Designer generation. When I refer to applications created using Designer generation, I do not mean the following:
· You open the Oracle Designer tool, create module definitions, hit a button, and wait for clean applications to pop out.
· All modifications are made by redefining the module definition and regenerating the application.
· The generated code is never touched.
The process described above is a fantasy that no one, to my knowledge, has achieved other than for very simple forms.
What do I mean by Designer generation?
· Predefined sets of generator preferences to support different types of forms.
· One or more templates to which to generate.
· Templates include special generator utilities to build complex objects and/or complex objects that can be quickly called from PL/SQL code.
· The typical method of application generation is to specify the module as much as possible in Designer, generate the code, make any necessary modifications to the applications in Oracle Forms Developer, and then design capture the changes.
In this environment, developers must be careful to make only those modifications that can actually be design captured. Record groups, LOVs, user parameters, and even handcrafted fields either cannot be design captured at all or lose information when captured. This means that you must have a careful set of design standards so that developers do not make these kinds of changes.
It is possible to perform Designer generation successfully. However, in order to accomplish this, the fundamental prerequisites are:
1. carefully specified preferences;
2. a good set of templates;
3. well articulated and enforced design standards;
4. developers skilled in both Designer and Developer environments.
The usual reasons given for generating applications using Oracle Designer are that it forces consistency in the applications and provides a Repository in which to neatly store the required information. Some argue that the Repository enables you to perform useful impact analysis. However, this analysis is limited to tables and columns. If you write complex triggers, the impact analysis will fail.
The Designer product was intended to support a development environment with the following characteristics:
1. Traditional relational systems.
2. Hundreds, if not thousands, of database tables.
3. Each table requires its own relatively simple application.
4. Hundreds of small applications must be coordinated and supported.
5. Large development teams.
We should no longer be building systems this way. Unfortunately, these characteristics still apply to many projects. A much more successful and efficient development strategy is characterized as follows:
1. Use generic modeling techniques.
2. Create smaller, more robust data models.
3. Build a small number of flexible applications.
4. Place as much information as possible into the database as business rules.
5. Use a small number of highly skilled developers.
This type of development environment eliminates most of the compelling reasons to use Designer at all.
Currently, Dulcian is building full ERP systems with a relatively small number of tables and a handful of developers using only the Oracle Developer Tool Suite.
Other reasons to rethink the use of Designer generation projects include the following:
1. Oracle’s commitment to the product seems to be wavering. Currently, there is much more emphasis being placed on the Repository and new JDeveloper product.
2. Other decisions made by Oracle regarding the Designer product include: Oracle has moved some of its top Designer talent to other areas. Last year, the Designer team was split up. Ian Fisher, the lead architect, is now working on the Repository. Dai Clegg’s UML effort has been merged with the JDeveloper team to create an integrated development environment (IDE).
3. As a member of the ODTUG 2001 paper review committee, I saw that there were only a handful of abstracts out of several hundred having to do with application generation using Designer.
4. The whole industry is moving toward Java, object-oriented design, and analysis techniques.
Another problem with the Designer generation method is that the Repository for Designer is and always has been different from that of Developer. Often, these two independent and somewhat incompatible Repositories try to store the same objects. I discussed this with Ian Fisher at a conference. He asked me how important I thought it would be for Oracle to deliver a unified Repository for Designer and Developer to allow developers to work seamlessly in either environment, depending upon their skills and preferences. I was very excited about this idea. Had Oracle been able to accomplish this, my opinion about Designer generation would be very different. This unification of Repositories was never achieved. To this day, the Designer and Developer Repositories remain independent and inconsistent.
Where is the market moving? In the user community, is there a demand for better generators? For Web generation, there is still some demand. There are enough organizations that have tried generation and failed that most are now wisely reticent about embracing a “100 percent Designer generation” philosophy. If anything, we are thinking of moving into an object-oriented UML environment. Ultimately, ERDs and the Module Designer are yesterday’s news. I suspect that, over time, application generation, as it now exists, will no longer be a viable development method and will be replaced by something new.
I do believe that there is a place for application generation in an organization’s development methodology. The idea of being able to specify a logical object within the database and get a generated application is a good one. Within Dulcian, we have been creating a generic object builder using a business rules Repository. This generic object builder allows users to insert, modify, and delete any logical object in the database. At some level, this is similar in principle to a generated application. However, the difference is that the application’s runtime behavior is modified based upon the business rules stored in the Repository.
I am not against application generation in principle. However, I believe that using Oracle Designer in its current state of development to generate applications is not worth the effort and will not improve in the near future.
It makes sense to commit to a product that Oracle is moving forward with and have a voice in its evolution. Oracle tends to be reactive rather than proactive in responding to the demands of its customers. Designer generation has been available for a number of years and only became viable in version 2.1. There have not been any significant improvements since the end of 1999.
If your organization has already been successful with this strategy, it may be worthwhile to continue. Likewise, if you are planning a new project and your tech lead and team are experienced in this mode of development, you may also be successful in generating applications with Designer. However, if your team is relatively inexperienced and you are trying to train new people, generating applications is not likely to produce satisfactory results. Using Designer successfully requires a huge learning curve. Your organization is unlikely to want to commit the time and resources necessary to get its developers to a level with this product that is required for its efficient use.