DAO (Dessign Pattern) with User restrictions

Question

I was wondering if there is a way of performing the next:

I have 2 kinds of user ( UserA , UserB ). A class Student and a class Classroom .

UserB has a List<Classroom> Classrooms; .

UserA can save a Student into any Classroom .

UserB can save a Student into a Classroom he ownes.

So, the StudentDAO has differents methods for each kind of user.

How can I do that? I think, the best way is:

In the constructor of the users, I instantiate a StudentDAO with the implementation that feets the user. Is that correct?

What if ClassroomDAO has the method getAll(); . UserA will see every Classroom . But UserB will see all the Classroom that he ownes. But this method will be the same that UserB.getClassrooms(); . 2 methods would do the same.

Thanks in advance.

Answer 1

You should not mix the data model and user roles. Even the sentence

UserB has a List Classrooms

should be reformulated as

UserB can access a List Classrooms

to avoid this confusion.

In your data model, you should have one single Student , not StudentforUserA and StudentForUserB . And very probably you should also have one single User with its role(s) as attributes. It's more than probable that you will have later more user roles and your class hierarchy would grow up uncontrollably.

You should also have one single DAO for each object type ( Student , Classroom ). DAO generally should be client-unaware. Unless your user type is somehow connected with your access rights control mechanism - but then you know who is logged in and your DAO return data or an exception according to the current user's rights.

It's perfectly OK to have access methods which throw an exception if you do not have sufficient access rights.

Now it depends on what UserA and UserB are:

1. User roles - based on something from the database, not known in design time. Then the DAO should throw an exception when trying to read the unwanted data and you should handle the exception higher so the user is politely informed that he is not authorized.

2. Different actors - something you already know in design time. Then simply do not call the unwanted methods.