devbanana posted on Wednesday, June 21, 2006
Hi,
Here's my situation.
My application has some members who can login,
register, etc. I'm finding I have a few types of member objects but not sure how
I should go about doing this.
Firstly, there should be an editable root member
object, for editing one specific member's information. Let's say a member wants
to edit their information, or an administrator wants to change some information
for that member.
Next, there should be a member list of some kind.
There should be methods that return a list of members, such as, FindAllMembers,
which retrieves pages of member data. I guess that this could be read only, but
it's hard to say.
However, there should be functionality for removing
members, and adding new members. I'm not sure if this should be done through the
list or the member object itself?
Assuming and hoping that can be done through the
top level Member object, I'm thinking of having:
Member (editable root)
MemberList (Read only list)
MemberInformation (Read only child)
I'll be making a custom provider that'll be using
some of the methods from these as well.
Also, there are going to be administrators,
employees, and customers, as types of members. Should these be separate objects?
Obviously, employees shouldn't be allowed to edit an administrator's data, but
an administrator should be able to edit an employee's or customer's information.
I should also be able to retrieve lists of administrators, employees, and
customers exclusively.
Most of these hold the same data in common, except
that customers have address information, which I was thinking could just be
profile information.
I'm starting to get better at this object oriented
design, but I'm a little confused on this base.
Thanks,
Brandon
cmellon replied on Thursday, June 22, 2006
Hi Brandon,
I would recommend create a Command Object to handle the delete. Then it would work like the following:
- Member list Displayed
- User selects the delete button/link
- new MemberDeleteCommand object created using selected member ID, and executed.
- Refresh List
Looking at your current design, that is what I would do as well in your situation:
Member (editable root)
MemberList (Read only list)
MemberInformation (Read only child)
I wouldn't create new objects based on their security requirements, the new Authorization stuff will help you out a great deal with this, you can set read/write permissions on properties depending on the users roles.
Regards
Craig
