This is more of a architectural question and I hope someone out there could enlighten me.
I’m starting the object model of my current project, and I can see that there will be various kinds of users, such as:
Clients
Photographers
Suppliers
Member
I would usually just add the semantic and categorization using a n:n relationship with a Group entity. However, I also detected that some of these “user kinds” might have additional attributes and business logic tied to them. For example, a Photographer will have a field of “cameras” that could even be a has_many relationship with a Camera entity. This could not be done with a Group alone.
I can see that both approaches, Group and STI allow you to:
Categorize and control permission.
Identify a user semantically in code and perform code depending on the “kind/group” of the user.
But STI is has some advantages if you want additional attributes and logic tied to the subtype model.
Group is nice to manage permissions and they can be changed, created and assigned to a user at runtime, something STI can’t do since it requires a ruby class in the filesystem.
I’m kind of confused on how I solve this issue, if someone has some tip or design principles to help me here, I would be really grateful!
This is just a thought, but you might be trying to do too much with STI.
If Groups work well for authorization, then use Groups for
authorization.
(btw, this approach sounds a lot like RBAC where a Group is like a
"role" in RBAC)
If STI works well for (whatever), use STI for that.
This means that you will have to keep the two in sync, but you should
also get
the benefits of both as well.
Yes, I was talking about RBAC, I just didn’t know the term at the time
Actually I think I can reformulate my original question as: “Is using STI to create subtypes of Users for access control a good practice/pattern?”
I’ve been asking this question in #rubyonrails, and found out that most people don’t use STI in the User model for access control. I think it could work for small applications, but bigger applications need something that can be managed at runtime, i.e: roles of users can be changed at runtime. With STI, your “roles” (subclasses of the User model class) aren’t made for being switched at runtime. Of course, you can change the type attribute, but that is awkward at its best, and creating new “roles” involves creating new classes at the filesystem.
STI works well for other more static elements, but for access control, hmm, I don’t think so. I don’t think a User model should have subclasses.
