I’m very frequently confronted with age-old problem of how to implement business objects with big amount of attributes of different types. The problem is bigger if requirements change frequently and list of attributes follows. Let’s implement it in classical ORM Entity style:
@Id
private Integer id;
private String name;
private BigDecimal price;
…and 50 more
Main CONS of this approach:
- Each change requires DB version migration, SQL script, test data rebuild etc.
- Each change propagates to all artifacts like Entities, business logic, DTOs
- Cause lot of boilerplate writing
- Can overload code in business object, especially when we use JPA annotations and write business logic in domain object
- Make database tables very big and thus hard to maintain and change
Main PROS of this approach:
- Simple and most commonly used, familiar to everyone
- Enable support of many standard tools like Java Validators, Lombok
- Simple in SQL queries and indexing, good performance
I’ve tried to remedy CONS of traditional mapping by creating framework which employ techniques like:
- making data model more flexible to avoid database changes, by removing all standard data columns and introducing new table with each row corresponding to attribute (look at https://stackoverflow.com/a/50971500/1638003, to my idea how it can be done)
- introducing attribute metadata in human friendly format like .xml, .csv, .txt or even possibly in .xlsx, this metadata defines attribute names, types, validation rules etc.
- generating all needed artifacts from metadata, we can generate DTOs and constants with attribute information transparently in maven generate-sources phase
I’ve managed to create simple, and fully typesafe interface with attribute framework, example usage inside business objects:
public void testBusinessMethod() {
setAttribute(TEST_STRING, "testValue");
String value = getAttribute(TEST_STRING);
}
In classical mapping it would look like:
public void testBusinessMethod() {
setTestString("testValue");
String value = getTestString();
}
It works great on paper, cuts down all boilerplate writing, make attribute change seamless and almost impossible to break, but I’m too experienced to be instantly enthusiastic about my creation, and I see it's obvious CONS:
- I must reinvent lot of wheels which can be done with classical Entities and all other stuff from Spring which works on POJOs, it is not fully KISS approach, with all consequences of it
- People working on it will need time to adopt to it and will dislike it like any other custom implementation
- Database schema is much simpler, but data retrieval always requires additional JOIN, and performance will not be cutting edge
So my main question is: Is it even worth to implement such framework ? Is there already made, simple alternative ?
