Model driven development can be a big factor in improving the efficiency of data solution development and the quality of the end product.
In order to successfully apply model driven development, tools are needed for modeling the application and generating the actual software based on the model.
This article compares a scenario where modeling and code generation is integrated in a single tool against one where separate tools are used for modeling and generation.
Example use case
For the purpose of this article we consider a simple scenario where the modeling requirements are as follows:
- Model data structures in the form of entities with attributes and relationships
- Model data flows that define what source data is needed for a certain target entity, including join conditions in cases where a target entity is populated using more then one source entity.
Based on the model information the following software components should be generated:
- DDL for the required tables
- SQL views that implement the data flows
- Stored procedures that read from the views and load to the target tables
When applying model driven development, one will always use a modeling tool and perform code generation somewhere in the process. In this article we describe the differences between having the code generation integrated in a modeling tool versus seperating the code generation.
Integrated code generation
When starting with model driven development it can be very conveniënt to have a modeling tool in which one can also create templates in order to generate the implementation. This will give a very quick start and from a user perspective there is only one tool involved.
An example of a modeling tool in which this is possible is SAP PowerDesigner. Custom modeling options and code generation can be created in a so called modeling extension (XEM).
Sample implementation in PowerDesigner
Out of the box PowerDesigner supports the modeling of logical data structures (entities, attributes, relations) and data mappings (source to target mapping on attribute level). An example customization could be a PowerDesigner extension that:
- Enhances modeling options so join conditions can be defined on a data mapping (something that is not possible with the default features)
- Implements code templates for:
- SQL Views based on the data mappings (using the join conditions from the modeling enhancement)
- SQL Stored procedures to load data from the views to the target table
- Orchestration jobs that invoke the stored procedure, for example in Azure Data Factory
Pros and cons
In the table below we listed the pros and cons of this way of working.
| Pros | Cons |
| Only one tool is needed |
|
Decouple modeling from code generation
Another possible method of applying model driven development is using a modeling tool purely to capture the logical model with it’s behavior. For a data solution this is modeled using entities, relationships, mappings and transformations.
In order to generate the code in this scenario, all metadata needed for code generation needs to be exported from the modeling tool into a format usable for a code generation.
In this scenario we would be using at least two tools, being the modeling tool and a code- generator. At CrossBreeze we use CrossGenerate as code-generator. This generator needs XML files as it’s model input, so in this case we can export all metadata into XML format using the modeling tool.
Pros and cons
In the table below we listed the pros and cons of this way of working.
| Pros | Cons |
|
Knowledge of multiple tools is required. |
Summary
At CrossBreeze, based on our experience with both approaches we prefer to decouple the code-generation from the modeling tool. In our perspective, the flexibility and performance gain outweigh the drawbacks of adding a new tool to the development stack.