Is it a good practice to return an empty component from the getter instead of null when all the members are null ?

Hibernate will return a null object but it's easier for me to work with non-null component if empty.

Is there a limitation if I do like this ?



Thanks...

Well, I guess you're doing that because of some use of your POJO in a JSP or something like that... I find it so despairingthat one has to modify/pollute the domain class so as to deal with a presentational problem...

For your problem, I guess Hibernate won't have any problem to understand your component is still a null one of every properties on it stay null.

So, if I were right above, apart from a big anti-pattern in my point of view (modify the domain class for presentational constraints...), this should not be a problem.

Yes, you're right it's for my jsps :(

But even in my business layer, it's simplier to work with empty component than check each time I access them if they're not null.

From an Hibernate point of view, when I store an object that is identical to the one in DB but that has empty components instead of null components, maybe Hibernate will execute an update query (with no values) because empty != null.
I have to run test cases to validate this...

IMO, it shouldn't. For example, Address is often mapped as a component. I find it a lot more easy to understand that, say, customer.getAddress() returns null because this customer has no address submitted yet instead of an anemic instance of Address.

Still imo, moreover, the thing is I think that the code that uses your API shouldn't have to know if some property is referencing a component or a real entity.

With this special component handling, customer.getAddress() would for example never be null, but customer.getBoughtItems() could be although this customer has neither Address nor bought items... I find it not satisfying 'cause there's no consistency between both usages.

Matter of taster, I suppose :-).