Re: Examples of Pojo Free Code?
Mark Levison <[email protected]> Mon, 14 Apr 2014 10:52:47 -0400
| Newsgroups | gmane.comp.programming.test-driven-development |
|---|---|
| Message-ID | <CA+UdPQ8N1qd_1rfnCD4jRDarUT5mqd-jta62JO=fJxgyAoDKkQ@mail.gmail.com> |
Adam - thanks for taking the time to reply. I showed this email to the person who had been making the comments and all of a sudden this isn't what he thinks he had been saying :-) I've never heard that before have you? Your advice and comments are overall sound. ORMs still bug me to a fair degree: 1. You have real classes with behaviour, a null constructor and setter's - ugh I hate setters they get misused by accident, people call them innocently and then all of sudden you have a class who's data is in an odd state and you've no idea when/how it happened 2. You wrap the Data Class in a Real class - avoiding the setter problem but relying on the convention that everyone remembers and never has enough discipline never to access the Data Objects. I would have more respect for an ORM that doesn't require setters, JPA (never used by me) seems closer to the mark than Hibernate (which I have used). Avi - in quoting the original person I think I misquoted POJO point. All thanks for the comments, insightful as usual. One last thing I would love to see an open source project that persists objects to a Database that you think does the job well, cleanly, effectively. My goal is to have a shining example of good code for the client when I next back in their neck of the woods. Cheers Mark On Fri, Apr 11, 2014 at 4:20 PM, Adam Sroka <[email protected]> wrote: > > > 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 <[email protected]> wrote: > >> >> >> I'm running an Agile Development course with some wonderful people at a >> client who're addicted to their existing ORM. We've been discussing the >> evil involved in Data Classes (i.e. classes with no behaviour). In their >> world the habit of creating data classes comes from the fact that their ORM >> (Hibernate and JPA) creates POJO type objects and they manipulate them. >> They get the problem but would live to see an example of project that >> doesn't do this. >> >> Do you know an OpenSource project that doesn't a use POJOs to get its >> data in/out of an RDBMS? Do you know an ORM that helps people avoid >> creating Data Classes? >> >> BTW I'm asking on this list lacking a better place. >> >> Cheers >> Mark >> >> >> -- >> [image: headshot-square-300x300]<http://www.flickr.com/photos/36331075@N00/9674877046/> *Mark >> Levison* | 1 (877) 248-8277 | Twitter <https://twitter.com/mlevison> | >> LinkedIn <http://ca.linkedin.com/in/marklevison> | Facebook<https://www.facebook.com/agilepainrelief> >> Certified ScrumMaster Training: Vancouver<http://agilepainrelief.com/courses/vancouver> >> | Edmonton <http://agilepainrelief.com/courses/edmonton> | Ottawa<http://agilepainrelief.com/courses/ottawa> >> | Montreal <http://agilepainrelief.com/courses/montreal> | Toronto<http://agilepainrelief.com/courses/toronto> >> Agile Pain Relief Consulting <http://agilepainrelief.com/> | Notes from >> a Tool User <http://agilepainrelief.com/notesfromatooluser> >> Proud Sponsor of Agile Tour Gatineau Ottawa <http://goagiletour.ca/> and Agile >> Coach Camp Canada <http://agilecoachcampcanada.wordpress.com/> >> >> > > -- [image: headshot-square-300x300]<http://www.flickr.com/photos/36331075@N00/9674877046/> *Mark Levison* | 1 (877) 248-8277 | Twitter <https://twitter.com/mlevison> | LinkedIn <http://ca.linkedin.com/in/marklevison> | Facebook<https://www.facebook.com/agilepainrelief> Certified ScrumMaster Training: Vancouver<http://agilepainrelief.com/courses/vancouver> | Edmonton <http://agilepainrelief.com/courses/edmonton> | Ottawa<http://agilepainrelief.com/courses/ottawa> | Montreal <http://agilepainrelief.com/courses/montreal> | Toronto<http://agilepainrelief.com/courses/toronto> Agile Pain Relief Consulting <http://agilepainrelief.com/> | Notes from a Tool User <http://agilepainrelief.com/notesfromatooluser> Proud Sponsor of Agile Tour Gatineau Ottawa <http://goagiletour.ca/> and Agile Coach Camp Canada <http://agilecoachcampcanada.wordpress.com/>