How To Organize Login Forms In A Website With Different User Accounts?

- 1 answer

I am developing a plain simple website using laravel 5 with different user accounts organized as follows:

Student and Admin inherit from User.

sample users table

  • name
  • username
  • password
  • is_active /* Only needed when admin is deleted. Every student will definitely be active (1) */
  • is_student
  • is_admin

sample students table

  • Contain some more unique fields for student

I could have thousands of students but just a few admins. Currently, my approach is to have a login box on the home page where both users can login and depending on the user type, display the appropriate profile page. Are they any risks to this approach or is they some better way to tackle this?


App Domain

  • Students register and apply for internship
  • Admin can do the following:
    • Manage comments on website (publish, delete etc)
    • Manage FAQ (Create questions and answers)
    • Add another admin user


Well, you could go this way, i guess it's a matter of preference. I would use a different model.

On models: I like DDD (domain driven design) and event storming to get insight into the domain I'm solving a problem for. On DDD:

In order to create good software, you have to know what that software is all about. You cannot create a banking software system unless you have a good understanding of what banking is all about, one must understand the domain of banking.

From: Domain Driven Design by Eric Evans.

Event storming is a workshop format for quickly exploring complex business domains.

I don't know much about your domain, so my answer is based on many assumptions. Nevertheless, it might come in helpful to you.

In this case, I guess I would separate all three concepts (Admin, Student and User). Even though they might share some properties, in the real world they are involved in different domains. Ignore that fact and your code will soon cover annoying edge cases and contain unnecessary complexity.

So, two different classes for Admin and Student. Both have a User. In my case, that would result in three different tables aswell. It might be possible that a Studenthas an Admin aswell (to ease administration, to filter overviews, and so on), but I'm just plainly guessing there.

In all three contexts, I would make use of immurable value objects, not just for code completion, but more importantly for encapsulating data, validation and exposing related behavior.

A User logs in, and after successful validation is redirected to the view for either a Student or an Admin. You'll notice that separating these domains will be a huge advantage when your application grows and becomes more complex. You could consider having a separate administration backend on a different domain, but for now I'd say that it would only introduce complexity, and hardly any value.

Maybe it's valuable to model what one is allowed to do in your system with privileges. As in: an Admin is allowed to do anything, a Student has one or more Privileges. This would create a flexible system in which some students can help with the administration. For example: maybe some students are in lead of some random study groups and need to be able to access study group administration. It might not be necessary now, so make sure your code is future friendly.

Other subjects I would look into: using CQRS or CRUD, and using an event store instead of a relational database (very useful if you want to be able to peek into or go back into history).

In any case: don't choose the newest acronym, always choose what best fits your domain (or context, or application).