Java наследование Hibernate Entities - PullRequest
0 голосов
/ 15 октября 2019

Справочная информация: Я создаю веб-приложение, которое позволяет учителям проверять своих учеников с помощью множества аналитических функций, помогающих измерить индивидуальную / классную успеваемость на тестах / викторинах. В настоящее время я занимаюсь редизайном схемы БД MySQL, и вы можете увидеть элементарную диаграмму EEF того, что я построил до сих пор: MySQL EEF Diagram for DB

Я на самом деле используюHibernate для создания соединения из моего бэкэнда в мою БД, но эта диаграмма EEF хорошо показывает связь между таблицами.

Проблема В настоящее время у меня есть отдельные таблицы для администраторов и студентови Учителя, потому что все 3 будут иметь уникальные поля, хотя в настоящее время они имеют очень похожие поля. Проблема с наличием трех разных таблиц заключается в том, что я хочу, чтобы учителя и учащиеся делились некоторыми функциями. Например, учитель должен быть в состоянии пройти тест так же, как и студент (для целей тестирования). Мой первый инстинкт - создать класс User, который расширяет и ученик, и учитель:

 public class User{
...
}
@Entity
@Table(name="student")
public class Student extends User{
...
}
@Entity
@Table(name="teacher")
public class Teacher extends User{
...
}

Этот подход завершает то, что я хочу сделать с моей службой приема тестов:

public QuizInstance takeQuiz(User u, QuizStructure struct){
...
}

, но яя не уверен, как я создаю отношения отображения, когда вовлечен полиморфизм. Хорошим примером этой проблемы является служба registerUser:

public void registerUser(User u, String password) {
        if(u instanceof Teacher) {
            //register User into Teacher Table..
        }else if(u instanceof Student) {
            //register User into Student Table...
        }
        new LoginService().createLogin(u, password);
    }
public class LoginService{
    ...
    public void createLogin(User u, String password){
        Login l = new Login();
        l.setEncrPass(encrypt(password));
        l.setEmail(u.getEmail());
        if(u instanceof Teacher)
            l.setRole("teacher");
        else
            l.setRole("student");
        l.setUser(u);

        //Save Login into Login Table in DB
    }
}
@Entity
@Table(name="login")
public class Login {

    @Id
    @GeneratedValue(strategy=GenerationType.IDENTITY)
    @Column(name="user_id", unique=true, nullable=false)
    private int id;

    @Column(name="email", nullable=false)
    private String email;

    @Column(name="encrypted_pass", nullable=false)
    private String encryptedPass;

    @Column(name="role", nullable=false)
    private String role;

    //How do I map User if it can link to either the Teacher table or the Student Table???
    private User user;
}

Я задаюсь вопросом, является ли это лучшим подходом к решению проблемы. Я не могу не поколебать, что дизайн моей схемы БД является проблемой, безопасностью и структурой. Может кто-нибудь сказать мне, если построенная мною архитектура БД плохая, и если да, поделитесь некоторыми примерами / ресурсами, которые помогут лучше проиллюстрировать более безопасные архитектуры для БД.

1 Ответ

1 голос
/ 15 октября 2019

Вот несколько предложений,

  • В этом сценарии требуется базовый RBAC (управление доступом на основе ролей).
  • Все пользователи, т.е. студенты, учителя, администраторы и т. Д., По сути являются пользователями системы, и всем им потребуется логин.
  • Итак, вам нужна таблица, которая определяет набор ролей, например, Admin, Teacher, Student и т. Д.
  • Для всех пользователей достаточно таблицы User. Эта пользовательская таблица будет иметь Role в качестве атрибута.
  • В целях безопасности, т. Е. Проверка того, разрешено ли пользователю получить доступ к данному ресурсу или выполнить операцию, может быть выполнена путем проверки его роли. Например, администратор будет иметь доступ к определенным страницам / операциям, которые недоступны для учителя и учеников.
Добро пожаловать на сайт PullRequest, где вы можете задавать вопросы и получать ответы от других членов сообщества.
...