It seems to me that an academic is not a user, although it seems to be. If it is not, it can not be inherited. You can force this to be true, and some will say it is, but I would not go this way.
An academic circumstantially assumes the ability to be a user. It seems to me that roles are not directly related to one as the child of the other, but rather that they interpose at a given moment, they only associate.
People tend to look at relationships in order to find things in common, but they are not the same thing, they are two different things that work together. In this case the association is more interesting.
What's best for this case I can not say. You have a few options.
The most obvious is to associate the academic with the user by creating a property or even a field that indicates which user profile it should adopt. This way you make the composition instead of inheritance . So when you need to use an academic adopts this type, you already need the user information he has will use the user type, with the facility of having direct access to it.
You may eventually want to make a two-way association and make it easier for the user to access the academic. I do not like this and can bring future problems if I change some concepts.
Have you ever thought that a user can be an academic and something else at the same time? Even if this is not true today, it will never happen?
It may be that the correct thing is to have another object that associates the various roles it assumes.
That's why modeling right at the beginning is important and should give you the flexibility to change whatever it is. You do not control the world. You can risk that the day will always have 24 hours, even this can change, although almost impossible, but one day someone can invent that it must have a decimal measure for the day and is accepted as such. But role relationships can change easily. If you change, do you have to reshape the entire system? Practically rewrite everything that involves this?
On the other hand I may be wrong, I have little information on the problem, and even if I had enough I could still be wrong. Some degree of risk we always have.
One of the things many people do not understand about object orientation is that the paradigm should facilitate modeling the system giving the chance to change any part without major trauma. Only conceptualizing very well is that it arrives at this, the code is just a detail .
Nor am I saying that every system deserves this effort. It's not always fancy.
If you make an inheritance in this case it seems strange to me, but it is not absurdly wrong, as in many examples we see where the person uses inheritance to join a car with banana because at one point he needs to use both in the same place. If this occurs I think that one of the Id s becomes unnecessary.
So I think it would look something like this:
public class Academico {
public int Id { get; set; }
public Professor Professor { get; set; }
public Usuario Usuario { get; set; }
}
or
public class Academico {
public int Id { get; set; }
public Professor Professor { get; set; }
public int UsuarioId { get; set; }
}
