Daniela Field on January 13, 2015
The data model is the foundation of your application; it is the equivalent of the underlying database tables. Mendix uses a default HQL databases for local testing. However, it can also use Microsoft SQL, PostgreSQL and Oracle databases, if you prefer.
You can define the following components directly within the domain model:
In this post, I’ll explain each of the main components and how they contribute to creating your application. We’ll use a test case throughout this post – consider the product ordering application example below. You can walk through the example with us by signing up to try the product for free.
Whenever you start a new project, think of the entities or Objects that you need to create in order to build your application. In this example, we’ll build an application to allow customers to order their own products.
To create this application, you’ll have a customer, an order, an order line – which is the information entity keeping track of both the product and the order – and the product. Each entity results in a table in the database with a unique key. The diagram below showcases our four entities:
After you have created your entities, you need to add more details to each entity (which is where attributes come into play). In our example, the customer might have a name or an account type such as VIP or general. The product might have a name or description.
As we fill out the entities, the details of the application will come to fruition. This system is incredibly helpful for developers who have to make adjustments or additions to the attributes mid project. It’s very easy to go back and add any other attributes that are needed. The diagram below illustrates how attributes are listed within our four entities:
We added names, an auto generated order number, along with a date of when the order was placed. The attributes are the equivalent of table columns and have an attribute type and size such as string, integer, Boolean and all the typical data types you need to build the application.
After we have determined the entities and their attributes, it is time to determine how they are all related. In this example, a customer can have multiple orders, an order can have multiple order lines, and each product can be ordered multiple times. The figure below represents the relationship between the entities.
That sentence was a mouthful, but you will notice how the relationships are visually represented through the associations. You can see that the customer to order relationship is 1 to many (as indicated by the asterisk). To take this example one step further, we can also include delete behavior between the relationships.
If a customer has orders, should I delete all the orders associated with the customer (known as a cascading delete)?
If a customer has orders, should we prevent the user from deleting an order (known as a prevention delete)?
Double click on the associations to see the behavior and how the delete option is configured. The delete behavior should depend on the business needs. Consider the following questions: Is it important to keep the customer when they have orders? Or it is more important to clean up the database and not have orphan orders when deleting customers?
These are good questions to ask the business users and will help craft the right business rules. The visual representation of this is either as blue (for prevention deletion) or red (for cascading delete).
The security of the application starts with the domain model, which is why these basic practices are so important to overall success. I go into greater depth on security best practices at this article. I strongly recommend that business engineers start implementing the modeler security on the domain first and then move onwards.
Questions? Did I forget to mention anything about the domain model? Anything I should cover more in depth in my next article? Let me know!
Receive Mendix platform tips, tricks, and other resources straight to your inbox every two weeks.