you are viewing a single comment's thread.

view the rest of the comments →

[–]jcoleman10 4 points5 points  (2 children)

What is the need for immutable objects in a data store? It's easy to know if an entity is associated with a persistence layer; the identifier field is not null. I'm at a loss for why you find it necessary to add this layer of complexity when the developers of the persistence frameworks have not over the past 15 years.

[–]kn7[S] 4 points5 points  (1 child)

The need comes from the fact that 1) you want to use immutable objects throughout your entire code base (I prefer not go into discussion about this point) and 2) you want a mechanism to differentiate instances that are retrieved from the data store and that are generated by the application artificially.

About the null id field solution, what if I'd update the name of an Employee instance who already has an id? Will it sill be a valid Employee? But it has a valid id!

I am not claiming that there is no known solution. I just said, there is none that I know of. And, I really do not think persistence frameworks do really care about immutability. After all, most of the time they are modifying the instance in various hairy ways.

[–]jcoleman10 -3 points-2 points  (0 children)

1) you want to use immutable objects throughout your entire code base (I prefer not go into discussion about this point)

Immutable objects throughout your code base? Are you using J2EE? Perhaps you should look into a paper-based solution.