I have a "Role" BusinessBase Object. Users is a child collection of "Role" Object.
What my client is saying is
After a quick review of the object model, we noticed some things that are not correct...
1) We are using the class-in-charge design pattern and all access to data needs to be done on the singular object. Collections are just containers for strongly-typed objects and should not have methods such as GetRoleUsers(int roleID) on the Users object. Instead, all of methods for retreiving objects should be contained on the individual object not the collection object. So in our previous example, the GetRoleUsers should be on the User object and should be named a little more accurately such as User.GetUsersForARole(int roleID) . All child collections should be lazy loaded.
I want to know what my client is saying is correct ot not.
As per the Project Tracker example we do have GetProjectResources in ProjectResources child collection class for retreiving the collection objects and hence I am a bit confused.
Please let me know which is the right approach.
Thanks
Mahesh Mahangare
Well I think you are correct - the collection class would be in charge here of loading up a list of User objects for a specified Role. It mioght be an editable collection or a readonly one just to let the UI pick the User object that needs editing. The User object would still be responsible for saving itself and doing all the insert/update/delete/select database work.
The User object represents one user so User.GetUsersForARole(int RoleID) does not make sense (to me at least).
I think the description is not clear.
There are 3 objects here: Role, child collection of Users and inside the collection is the User BO.
If the client really said that you need to fill the collection from a method on the User BO - then it does not make any sense. Perhaps they said, the method should be in the Role BO instead of the collection itself? That makes sense as the Role BO is then capable of fetching a child collection.
I put the methods on the collection itself though.
Joe
Copyright (c) Marimer LLC