Object confusion

whelzer posted on Tuesday, July 22, 2008

I'm putting together a User Admin UI for my app.

In terms of objects I've got:

User - inherits from BusinessBase, has usual properties (user full name, user name, etc) and a collection of Roles.

So far so good...for the Roles collection I was thinking of:

RoleInfo - inherits from ReadOnlyBase (RoleId, Role, Role Description)

and RoleList - inherits from BusinessListBase and manages a collection of RoleInfo objects which needs to be editable.

It seems I can't do this? Neither BusinessListBase and EditableListBase can have Read Only object as their collection object. Am I reading this correctly? Does this make any sense??

Any help much appreciated.

RockfordLhotka replied on Tuesday, July 22, 2008

You don't have quite enough objects to meet (what I think is) your use case.

You need this to edit the user and their roles:

User <- BusinessBase

UserRoles <- BusinessListBase

UserRole <- BusinessBase

And to show the list of available roles:

RoleList <- ReadOnlyListBase

RoleInfo <- ReadOnlyBase

And to admin the list of roles itself:

Roles <- BusinessListBase

RoleEdit <- BusinessBase

whelzer replied on Wednesday, July 23, 2008

Rocky,

Many thanks for the reply, I only mentioned "block 1" in my first post to keep things simple.

Why would UserRole inherit from BusinessBase? In my mind it is merely a 3 attribute object - RoleId, RoleName & RoleDesc.

It can not be changed at this level - I was thinking a ReadOnlyBase object would be more appropriate, in fact that is was I had built, I then discovered that this can not serve in a writable collection...

I need to move on so I'll make it BusinessBase but am still very interested in your thoughts.

triplea replied on Wednesday, July 23, 2008

I had a similar scenario recently where it would appear that the most logical structure would be (translating it into the current scenario):

User <- BusinessBase

UserRoles <- BusinessListBase

UserRole <- ReadOnlyBase

Of course this is not possible thats why I had to restructure the hierarchy like Rocky suggested. It would be a nice shortcut but then again it would probably muddle up object responsibilities... Just make sure all your properties in UserRole (BusinessBase) are read only and that you keep your read-only list in sync and you should be fine.

RockfordLhotka replied on Wednesday, July 23, 2008

It is all about object responsibilities.

UserRole may be simple, but its responsibility is to represent the connection between a user and a role. It is an active participant in the use case, and is an editable object because it needs to save its data (the relationship) to the database when the User object is saved.

Read-only objects only have read-only properties, but also they can not be saved to the database. They have no support for DataPortal_Insert/Update/Delete. Why would they? They are read-only.

But you actually need to save this data (simple though it might be), and so you need an editable object (even if that object’s properties are read-only).

Rocky

ajj3085 replied on Wednesday, July 23, 2008

Nothing wrong with having a BusinessBase object that has only readonly properties. You use it because you pretty much have to.. and it makes sense. Anything that can write to the database should be a BO.. it's not readonly otherwise, even if the user can't directly change the instance properties.