0

I have a Tomcat app that uses Entities that are autogenerated from Eclipse/JPA. I then have hand coded DAOs that interface to the database.

I see a significant benefit to keeping the Entities simple. e.g. the spec says it must have a blank constructor. Leaving them alone means I can regenerate them if the database schema changes. But I am being tempted to extend them.

A couple of issues...

If I create a new entity, I would like certain fields to have non-null values. If I have an empty constructor, I can't do it there. e.g. status='New', Date created = new Date() etc.

I realize I could use a Factory. But should that live say within the DAO instead? e.g. DAO.getNewObject()?

Similarly, if I want to use test or validation logic, where does that go? e.g. completeness score = if name, address, phone, etc are filled out? Should this kind of thing live in the DAO? or the Entity? or something else?

Should I have a new Class that extends the Entity and put the logic in there?

Is think kind of architectural stuff covered somewhere?

PrecisionPete
  • 3,139
  • 5
  • 33
  • 52
  • Yes. But I did not use them to build this. And I'm not switching in mid-stream... – PrecisionPete Sep 10 '14 at 19:49
  • > I can regenerate them if the database schema changes. < How often you will regenerate your objects? Even if schema will change, it shouldn't be that big changes, and you will be able to change that in your JPA entities. Default constructor doesn't mean it has to be empty. For sure you can put there your initialization logic if it is more logical/useful for you. All these tools should make your development easier, not to force you to do some strange, bad designs. – Gas Sep 10 '14 at 22:19

1 Answers1

0
  1. For validations like NotNull, MinLength, etc consider using a suitable JSR303 compatible validator
  2. For some business validations there are two approaches: Using a separate validator class or Having validations in the object itself. I sometimes do standalone validations in the object itself. But if the code gets bigger, then it is better to separate/decouple the validation into a validator. (Spring can help you bind separated validators with services.) However, I wouldn't suggest having the validation logic in DAO. Data Access Objects should be used for accessing data. Assuming your database contains validated data, the validations could be performed at a much higher level. You can pass your object to validator methods instead of extending anything.
  3. Validator classes extending entity classes is not a good idea.
  4. Where should you validate the objects? IMO you can validate when objects or data are passed across boundaries. Most particularly when objects are created from request data (controller layer). Also,validate or make defensive copies when objects are mutable.
  5. As Nathan mentioned timezone (and currency, char encoding, etc) issues could be tricky down the line. So arrive at a standard. This will help minimize validations and conversions.
Community
  • 1
  • 1
Atul
  • 2,673
  • 2
  • 28
  • 34