Well that is an often asked question so maybe I am the one who is naive? ;-)
The fortress api has 3 layers: 1. manager - these are the public apis called by the outside client 2. process - this are where the entity specific validations and flow occurs. This layer is hidden from outside clients. 3. dao - of course this is where all the ldap data access code goes. We could fold the functionality contained within the Process layers into the DAO layer. I don't have strong feelings about it but have a mild preference to leave it as is. I doubt it makes any difference in terms of efficiency and keeping the validation separate may benefit us if/when sibling DAO components are added. For example the unbound and apache DAO components did not each have to implement data validations or other business rule processing. This layer is hidden from outisde clients. On 11/06/2014 12:59 PM, Emmanuel Lécharny wrote: > Hi, > > we discussed in FC-42 the opportunity of using a shared ldapConnection > accross many operations. Now that the pool does not validate or re-bind > teh connection when we are done with it, the need to share the > connection is less critical. > > Although I wonder if it's still a good idea to have two classes, like : > o AdminRoleDAO and AdminRoleP > o AuditDAO and AuditP > o OrgUnitDAO and OrgUnitP > o PermDAO and PermP > o PolicyDAO and PolicyP > o RoleDAO and RoleP > o SdDAO and SdP > o UserDAO and UserP > > Why can't we move the logic from xxxP to xxxDAO ? > > Sorry if it sounds like a naive question... > >
