daily quotes
Programming is not a zero-sum game. Teaching something to a fellow programmer doesn't take it away from you. I'm happy to share what I can, because I'm in it for the love of programming.
Search
Recent blog posts
- Will Hibernate Switch From Maven to Gradle?
- Javarsovia 2010 - been there, done that
- Gradle talk on Javarsovia 2010 - presentation, source code and comments
- How to Make Your Geeky Presentation Worse
- Builds Are Complex So Choose Your Tools Wisely
- What is "Done"?
- Gradle talk on Javarsovia 2010
- Invoking m2release plugin on Hudson with cURL
- Gradle talk - Java Camp #3, 10 April 2010 - slides and source code
- Gradle talk - Java Camp #3, 10 April 2010, Cracow, Poland
Validation is a part of some specific case and model is general.
Very bad approach is to mix the "description of structures" (bean/entities) with a very specific to the case implementation.
CORBA and EJB 1-2.1 Entity Beans showed us how bad it was.
Session Beans, Web Services and SOA are examples of old good structural approach - not object oriented one.
In large systems, domain model is generated from from UML, and need to regenerated very often - where is a place for validations function, how to preserve the from be overwritten?
Model might be generic, and very elastic, with reuse and inheritance of entities like Address, Person, etc. What if domain model (set of bean/entity classes, of course) is common and critical resource for the large system, and different teams reuse this holly model - should every developer be free to rubbish entities of the model with some very specific validation?
More, ORM and relational to object mapping allows for multiple inheritance in database, and domain model might be not very clear, with "repeats". Where to put validation function in that case?