don't even think of manually producing separate views of - basically - the same thing.
These views are:
- the UML class diagrams
- the JPA Entity models
- the DDL to create the tables backing the Entities
- the SQL Insert statements to generate reference/test data
- the XML datasets to populate the DB fefore each Unit Test
- the XML datasets to assert the content DB after each Unit Test
If you do all this by hand, I can guarantee you will waste a lot of time and energies at each minor refactoring. Mainly because things which are loosely or not connected at all (XML, SQL...) break silently and most of the time you will find the problem only runtime.
this is an application where each layer has been generated painfully and manually by a herd of monkeys
this is an application where all artifacts have been generated from a single repository
Design time validation is a LOT better than Runtime validation, so....
Build only ONE metamodel - if you dare you can be Java Entities with JPA annotations, but I am not 100% sure this will cover all your needs.
Otherwise build your own metamodel and use it to generate all the rest.
Datasets (INSERT ox FlatXML) can be generated by hand coded Entities. The advantage is that when the model changes, Entities break and you just have to follow the red in Eclipse.
Lesson number two: Use RICH DOMAIN MODEL
Encapsulating rules and behavior inside your model makes it A LOT easier to refactor and test your code.
Lesson number three:
Your service code should never have a direct write access to the Domain objects. Every "operation" should be expressed by a verb which explicitates the use case you are executing.
No comments:
Post a Comment