[RFC] Separate View and DB Hydrators

[claytondaley]

My impression is that the underlying logical architecture of the Zend Form is really:

DB <=> Hydrator <=> Object <=> Hydrator <=> Form

It seems to be common (and is the case in ZfcUser) to use the same Hydrator for both of these stages. I'm trying to understand if it's really a requirement that needs hard-coded into the ZfcUser service. My thought is to use two different hydrators to create a (ZfcUserAdmin style) user list:

• For the DB <=> Object link, I'd like to use DoctrineObject hydrator for built-in graph traversal.
• On the other end (View <=> Object), I could tweak a simpler (e.g. ClassMethods) hydrator to take each user in my list and dehydrate it down to an array for rendering.
  • I believe I could use a (de)hydration strategy to take advantage of the graph traversal to grab a field from a related entity (like the name of a Usergroup otherwise linked only by an id).
  • As an added bonus, I could add strategies to the view hydrator to format DateTime (or any arbitrary type) in a view-specific way. With a single hydrator, this hydration strategy would also affect the database -- probably not what I'd want.

The SQL user in me abhors the idea of getting this data without a JOIN, but that seems to be the ORM ethos. Does this strategy make any sense? Is there a better way to populate a table that needs JOINs... such that this idea creates unnecessary complexity.

I realize this could (and maybe should) be a StackOverflow question, but I'm specifically interested in using this strategy in the ZfcUserAdmin user list context... which depends on the service in ZfcUser so this is the place where the rubber hits the road.

[claytondaley]

Obviously, the same philosophy could be applied to forms. In theory, you could use the DoctrineObject hydrator for both stages here, but Doctrine refuses to fully support underscore naming -- and ZfcUser currently uses this strategy for display_name. Even if display_name gets moved into a different module (an idea tossed around in #526), ZfcUser modules need to extend forms using a consistent naming scheme and underscores seem the implicit choice. It'd be far simpler to standardize on ClassMethods (with underscore naming) for the form end of the relationship while allowing users to customize the DB side to their needs.

[claytondaley]

With some additional digging, I see that this is implicit in the current architecture. There's a setting for the User hydrator and the forms defer to the default (ClassMethods) when they extract().