See the main page on BeanReasonableness for the core principles of BeanReasonableness. This page is a repository for (early) thinking on the rationale behind BeanReasonableness, with a special emphasis on Hibernate. We will begin with a now defunct component of BeanReasonableness, rule 3 -

3. As any serialisation operation starts, the contents of the bean container are to be considered "dead" - no weird dynamic activity may now be triggered, and they are to be considered equivalent to the same model as implemented in Peas. To get this to actually work in the face of beans provided by someone who isn't following this model requires some obstinacy

Why is such a convention desirable?#

The initial crop of "pure bean" frameworks (with front-runners) JSF and Hibernate are proving that there is still more to the definition of a programming object than its interface. Both JSF and Hibernate claim to allow you to "keep programming the way you always did" by not intruding visibly into your code, but anyone who has ever tried to use the self-same set of objects as both a JSF bean model and a Hibernate model (e.g. we at CARET, and this enterprising chap) can tell you that the most "hilarious" and opaque disasters are waiting to engulf you. Getting a Hibernate model correctly tuned in the presence of cascade operations and lazy evaluations is at best "fiddly" - doing so in an environment where unseen and undocumented code is reflectively traversing your model is essentially lethal.

What has gone wrong here?

Whilst the issue of allowing a "free interface" is now resolved, we are still some way from winning the battle. The semantics behind an interface are at least as important as the interface itself - and in fact the pressure to create apparent agreement on interface has led to the situation (e.g. between JSF and Hibernate) becoming momentarily EVEN WORSE than it might have been had the interfaces been dissimilar. When problems occur, the code actually implementing or manipulating the interfaces is hidden much further from view than it would have been had they been operated traditionally (stack traces now misleading, tracing hard &c), and the mismatch between expectations between client and producer is much more obscure, being wholly semantic.

Hibernate, for example, uses dynamic proxying implemented using bytecode engineering, to transparently intercept requests to "lazily evaluated" bean properties, and either trigger a database load or rescue the required data from one of various levels of caches. This creates a slightly distressing situation where "what you see is rather surely not what you get". An innocent call to an iterator(), size() or even a simple get() might trigger the most awful cascade of expensive operations. This is all very well you may say, since it represents light-years worth of improvement from the days when we had to fiddle around with JDBCResultSets and do horrid type conversions all by ourselves. But this represents a very real problem when you attempt to hand such beans over to a vast clunking framework like JSF which will traverse your model in numerous unexpected, undocumented (and in fact implementation-defined) ways[1]. This is partially an issue with Sun's somewhat neglect of developments in the wider open source community, and partially an issue that JSF is simply too large, heavyweight and intrusive.

To be sure, Hibernate are much more to be supported in this dispute, who have done a marvellous job of bringing database communications out of the dark ages, and who could only be blamed for being a bit too zealous in trying to hide the last traces of complexity under the carpet. But it brings out the very real point that for a framework to be truly reasonable, it must do its best to document the INTENT and USAGE STYLE behind its interfaces. This is of course rather hard - uncovering ones hidden assumptions is a lifelong task, and API documentation (even Sun's) is becoming considerably better in this area, at least in such basic areas as documenting thread-safety and the lack of it (unfortunately usually inclining to the latter except where things are synchronised).

ANYWAY, the upshot of this discussion is that in order to be reasonable, RSF tries to explain the usage model behind its beans, and tries to make this explanation as simple as possible by "trying not to do anything funny" with them.

---

[#1] As an aside, it is worth looking at the contortions people generally have to go through to get JSF and Hibernate to sing from the same sheet. This enterprising chap has devoted some time to it, but has had to duplicate his entire data model into two sets of controllers. This is, unfortunately, generally the sort of thing that has to happen... and recall, this is one of the "with less coding" approaches!