beberlei wrote: > > The approach you are describing is misusing Zend Entity as a data access > layer only, however its purpose is really managing of object identities. > Although its possible to dynamically set a different metadata model based > on properties its really not recommended at all and there will be no > support with whatever > problems might occur with this use case. > Not sure how you are seeing my strategy as data access only. The only thing different from its intended use is that I am dynamically determining the object at run time. The equivalent would be to create sub-classes to handle different combinations of properties. For complex objects Zend_Entity helps a great deal. If, using your example code, I don't need to display an engineer's bugs in a particular view, I don't load bugs at all, not even a collection stub, because it will never be called. I understand that your lazy loading methods are intended to minimize the impact of this, but it seems reasonable to take this even further and give no awareness of the unneeded object at all. It doesn't break your intent IMO. It's just an additional valid use case for someone who is already managing property lists as part of the ACL scheme.
beberlei wrote: > > Instead a good use-case would be nest the ACL inside your entities and > allow the request of certain data/relations only if these acls are meet. > This way you push the access of different properties to the domain model > and abstract from the persistence, which is what Zend Entity is about. > The ACLs in my application are very complex because individual rights to particular actions on particular resources are administrable by third-parties, thus the building of objects must be entirely dynamic. The ACLs also drive the automatic building of menus and forms, thus they must reside at the higher domain model layer for the purpose of creating dynamic objects (for security and performance). beberlei wrote: > > It seems however with what you describe Zend_Db_Table is a pretty good > access strategy for your relational data, > Yes, Db_Table is my current data access layer, but as mentioned at the beginning of this thread, Zend_Entity would be a much more functional layer between my Model and DbTable for at least these reasons: 1. It includes an excellent *object-aware* SQL builder. (my current implementation uses separate manually created versions of queries for each significantly different set of property lists -- typically, there are 2-3 different queries for each model) 2. It has abstracted *object-aware* getters and setters. (I have this functionality but yours are more properly abstracted and I'd prefer to use ZF components as much as possible) beberlei wrote: > > Zend_Entity however is about objects that are instantiated completly. > Partially loaded objects won't be supported. > It seems that if def objects are dynamically built, Zend_Entity will not be aware that it has a "partially loaded" object and supporting that usage should not be an issue. The only significant mismatch is that I would not need the lazy loading features in Zend_Entity. However, they don't get in the way either. I think Zend_Entity is an awesome addition to ZF. It makes much more sense to leverage what you are building rather than building my own components. -- View this message in context: http://www.nabble.com/Zend_Entity%3A-Using-it-in-a-fully-model-driven-manner-tp25374495p25388335.html Sent from the Zend Framework mailing list archive at Nabble.com.
