• Post Reply
  • Bookmark Topic Watch Topic
  • New Topic

[iBatis] Focus on POJO development

 
hernan silberman
Greenhorn
Posts: 27
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
I have another comment and request for the iBatis developers. I've been working on lots of new code and I start by designing the Java classes I would prefer to work with and support. They usually look like this:



If I need to persist this class to iBatis, I end up having to make lots of concessions and it looks like this (using latest version 2.2):



* Fields are no longer final.
* Had to add a public constructor.
* Had to add a private setter for Data1 (but I'm happy it can be private in 2.2)
* Had to lose the Collections.unmodifiableList() wrapper on my getter for the List<Somethings>

(I'm new to iBatis so I may have missed something, please feel free to point those out).

Anyhow, I'm not a super-picky but I wish I didn't have to think so hard about persistence when I write my Java code. I know there's work in progress to help make this better with iBatis, so consider this an additional "yes, please"!

thanks...
hernan
[ December 07, 2006: Message edited by: Bear Bibeault ]
 
Gregg Bolinger
Ranch Hand
Posts: 15304
6
Chrome IntelliJ IDE Mac OS X
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
Just curious, why would you want bean properties final in the first place?
 
hernan silberman
Greenhorn
Posts: 27
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
Well, in the example I came up with above the class represents an immutable class. No set methods, everything is passed in through the constructor and does not change.

Making the members final when they can be gives me some assurance that a maintenance programmer won't try to reassign them in the future--at least not without (hopefully) thinking about it as they delete the final keyword.

It's not critical, but I like to use the compiler as a shield whenever I can.

hernan
 
Bear Bibeault
Author and ninkuma
Marshal
Pie
Posts: 65335
97
IntelliJ IDE Java jQuery Mac Mac OS X
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
Originally posted by Gregg Bolinger:
Just curious, why would you want bean properties final in the first place?


It's a common pattern to follow for DTOs (Data Transfer Objects) that are to be considered immutable.

The lack of a setter can suffice to enforce the immutability, but the final keyword ensures that the value can only be set upon construction.
 
Bear Bibeault
Author and ninkuma
Marshal
Pie
Posts: 65335
97
IntelliJ IDE Java jQuery Mac Mac OS X
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
bonk!!!
[ December 07, 2006: Message edited by: Bear Bibeault ]
 
Gregg Bolinger
Ranch Hand
Posts: 15304
6
Chrome IntelliJ IDE Mac OS X
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
Aha! I didn't realize that, though I did the class was immutable. I just haven't personally thought to do so. Good to know. Learn something new every day here on the Ranch!
 
Clinton Begin
author
Greenhorn
Posts: 21
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
Good points. Constructor injection will solve all of that. The .NET version already has it. We just haven't made it a priority yet on the Java side.

Cheers,
Clinton
 
  • Post Reply
  • Bookmark Topic Watch Topic
  • New Topic