I am looking at trying to rewrite an application that is mostly procedural to an MVC/OO approach in order to teach myself a deeper understanding of both.

BUT, I am having some conceptual issues with the current group/access control that is used.

We have Groups (Businesses) that have role based users (Manager, salespersons, customers). They can have customers either assigned to a salesperson, or not. The manager sees everything, the salesperson only those customers assigned to him.


The table structure for this currently is something like this:

users (userID [demographic info])
business (businessID, userID, et al [demographic info])
salespeople (salesID, businessID, userID [just foreign keys])
customers (customerID, businessID, userID, et al [demographic info])
salesAssignments (salesID, customerID [just foreign keys])

The Manager can affect everyone within that businesses group (everyone has a businessID that links them to that business and no other). The customers can login and make minor changes to their profiles or interact via messaging to their salesperson or the businesses manager.

Added Spice to the mix: (comment on any of these if they apply to your insights to the above question) Is there a better way to have similar user access and control? I want to rebuild the site with an API that can be used by both the web app and mobile apps.

EDIT My main conceptual hangup at the moment relates to how to recreate this structure in a user object for the OO part of the application. Now everything is accessible via session variables, or queried from the DB via procedural functions. Again my understanding of OO is limited, and this is an attempt to figure it out.


Create a user class, and then a class that inherits from it for each kind of user. Add a collection of type as appropriate to each of these classes for the child relationships e.g.

class User {}

class Manager : User
    Collection<SalesPerson> SalesPeople { get; set; }

class SalesPerson : User {}

Now, when you have a manager, you can navigate into the related sales people (assuming the list is correctly populated)

  • Have you considered using XACML to define the authorization? – David Brossard May 6 '14 at 9:40

Conceptually, the way you achieve this in your repository is to limit your database accesses by adding a WHERE clause to your SQL, to the effect of:

WHERE <User is manager> OR UserID = <currently logged in employee id>
  • 2
    Perhaps I misstated the area of my conceptual issues. I understand the SQL part of it, but am very limited in my understanding of OOP and am trying to warp my head around how to recreate this structure in the user object. – jayhoakan Dec 11 '13 at 23:31

You could implement permissions using the type object pattern http://gameprogrammingpatterns.com/type-object.html

So each of your users would have a type property that defines their type in 1 of 2 ways.

  1. differing type object properties eg. typeName
  2. type object inheritance hierarchy

1 has the advantage that all type objects are of the same class and thus can always be treated identically and it is quite simple to interrogate an object's type.

2 has the advantage of specifying differing type properties that apply only to that type (and it's subtypes), eg. the Manager type may have the property groupSalesTarget which might not make sense for a customer

One of the big advantages of this pattern in general is the ease of upgrading and downgrading the permissions of individual users.

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.