|
Re: Modelling a business rule
|
Posted: Aug 29, 2003 9:10 AM
|
|
Assuming you are using a relational database as the back-end for your application, and that you have a table (say "User") containing info on each of the users, then you would have another table called, say, "Role", listing bundles of permissions associated with different types of people (like "Administrator"), a table called "Permission" which lists all of the permissions you'd need to check, and then a couple of tables to manage the many-to-many relationships between User and Role and between Role and Permission. The first, table, which you might call "User_Role", consists of keys to users and roles--each role that a user has is encoded in one record of the table, which has the user's id number (or whatever primary key you're using), and the role's key also.
The "Role_Permission" table does the same thing to indicate which permissions are associated with the different roles.
Then, to check whether a user can do something, you can do a join on User_Role and Role_Permission, filtering by the user's id, to get a list of permissions for the user. You could have one object whose job it is to check permissions for everybody else.
You also seemed to indicate that some of the permissions were dependent on other data; i.e. not simply "He can do this because the sys admin says he can", but "She can do this because she is a level 5 wizard making over $55K per year". I would include one or more classes to implement these rules, and have them called by the class you use to manage user info. Then just have that class update the user_role table based on the user info as the info is updated. That way those classes, and those classes only, worry about the relationship between user info and roles.
Just my $.02 worth.
|
|