|
There's nothing about the ORM that forces them to use data classes. The framework typically requires you to follow some conventions and/or configure some options so that it knows how to match types. Also, you typically have to provide a no-arg constructor so that it can instantiate objects for you. Otherwise, they call them "plain old java objects" for a reason. They can and should have behavior.? My advice would be the same as for any heavy framework use: 1) YAGNI?? 2) Test-drive a wrapper around the framework APIs you intend to use so that you can reference them directly in only a couple of places. It blows my mind why more people don't do this.?
3) Use a gradual changeover or parallel change strategy to move current uses of the framework to the new wrapper. This could take months or years to fully complete depending on how large and complex the legacy code is. Prioritize new functionality and/or areas that have caused you difficulty in the past.?
Beyond that, it sounds like there is a interesting cultural/educational problem. I would want to investigate to understand why they believe something that is clearly false: ORMs force them to write poorly factored and/or non-OO code. This is simply not the case. For example, Industrial Logic uses Hibernate in their eLearning product code (written in Java) and there are plenty examples of well factored classes in there.?
I have also run into a tendency to: ?a) copy contrived examples from the ORM documentation that needlessly couple you to the framework then blame the framework.? b) misinterpret some design book as suggesting these are ORM "best practices." For example, Domain Driven Design, by Eric Evans, seems to be misinterpreted as saying that persistent "Entities" are just data and "Services" operate on that data. He describes both of these patterns but never says that they should be implemented that way.?
If you convince yourself that all the behavior belongs in static services (libraries) and all the data belongs in data classes (structs) then you should really be writing in C. That's not a knock on C. I love C. Java was designed for a different paradigm, though, and if you are going to work with it professionally you should know what that is.?
On Fri, Apr 11, 2014 at 10:50 AM, Mark Levison <mark@...> wrote:
|
