Mod4j: Modeling for Java using Domain Specific Languages

Unexpected create objectbehavior with nullable attributes with default values

Details

  • Number of attachments :
    0

Description

Consider the following example:

BusinessDomain customers
Class Customer [
boolean blacklisted nullable default false
]

If I create a Customer on the business layer I use in Jave:

Customer c = new Customer();

This will result in a new customer object with "blacklisted" having the expected default value "false".
If I create a new Customer through the service layer I need to do this by defining a "create" method in the Servcice DSL. This takes a DTO as a parameters. For example the datacontract and service models may look like:

DataContract data
from customers import Customer
BusinessClassDto FullCustomerDto base Customer

and

Service servicemodel
from data import FullCustomerDto
create createCustomer for FullCustomerDto

This is used from Java using (localservice is the generated serviceclass) something like :

FullCustomerDto custDto = new FullCustomerDto();
FullCustomerDto createDto = localService.createCustomer(custDto).

I now get the unexpected result that the newly created Customer object does not have thne default value "false" for the attribute "blacklisted".
Why, I'll explain.
The dto object "custDto" has a value "null" for "blacklisted" because this has not been set.
Becuase the "blacklisted" attribute is nullable, "null" is a vlaid value for it and the translator (from dto to business object) will call the setBlacklisted() method of Customer with the value "null". As a result the default value is overwritten.

This lads to the strange behavior that if I do not set a nullable attribute with a default value in a DTO the created business object will never get the default value for this attribute. This surely is unexpected behavior.

Thre are at least three solutions:

  • forbid that attributes with a default value are nullable. The setBlacklisted(null) will then not be called in the translator.
  • add the default value to the data contract. The DTO will get the default value for the attribute, just like trhe business object does. In this case the DTO object is created with all the correct default values. Note that this will lead to unexpected behavior when a DTO object is created to be used as an example object for the fuindByExample(). This find will then only find objects wioth the default values unless they are explicitly set to null buy the developer.

My first impression is that the first solution is the one which will lead to the least surprise.

Issue Links

Activity

Hide
Johan Vogelzang added a comment -

In option two it is not nescecary for developers to set all the default values to null, currently they are explicitly set to null in the constructor of the example classes. So its taken care of.
Option two solves this issue and clients could benefit from having the default values at hand.

Show
Johan Vogelzang added a comment - In option two it is not nescecary for developers to set all the default values to null, currently they are explicitly set to null in the constructor of the example classes. So its taken care of. Option two solves this issue and clients could benefit from having the default values at hand.

People

Vote (0)
Watch (0)

Dates

  • Created:
    Updated:
    Resolved: