Главная страница
Навигация по странице:

  • public

  • Инструкция по созданию бизнесобъектов. Strategy это поведенческий паттерн, выносит набор алгоритмов в собственные классы и делает их взаимозаменимыми


    Скачать 0.73 Mb.
    НазваниеИнструкция по созданию бизнесобъектов. Strategy это поведенческий паттерн, выносит набор алгоритмов в собственные классы и делает их взаимозаменимыми
    Дата13.11.2022
    Размер0.73 Mb.
    Формат файлаdocx
    Имя файла2.docx
    ТипИнструкция
    #785689
    страница20 из 26
    1   ...   16   17   18   19   20   21   22   23   ...   26

    33. Как мы можем добавить секьюрность к контроллеру (минимум 2 способа)?


    Класс настроек:

    1. Метод configure();

    Аннотации:

    1. @Secured и @RolesAllowed (эквивалентная аннотация JSR-250)

    @Secured({ "ROLE_VIEWER", "ROLE_EDITOR" })
    public boolean isValidUsername(String username) {
       
    return userRoleRepository.isValidUsername(username);
    }





    @RolesAllowed("ROLE_VIEWER")
    public String getUsername2() {
       
    //...
    }


    2. @PreAuthorize и @PostAuthorize (обеспечивают управление доступом на основе выражений SpEL (Spring Expression Language) до и после выполнения аннотированного метода)

    @PreAuthorize("hasRole('ROLE_VIEWER')")
    public String getUsernameInUpperCase() {
       
    return getUsername().toUpperCase();
    }





    @PostAuthorize("#username == authentication.principal.username")
    public String getMyRoles2(String username) {
       
    //...
    }



    3. @PreFilter и @PostFilter (обеспечивают фильтрацию коллекции, переданной в качестве аргумента до и после выполнения аннотированного метода)

    @PreFilter("filterObject != authentication.principal.username")
    public String joinUsernames(List usernames) {
       
    return usernames.stream().collect(Collectors.joining(";"));
    }





    @PostFilter("filterObject != authentication.principal.username")
    public List getAllUsernamesExceptCurrent() {
       
    return userRoleRepository.getAllUsernames();
    }




    34. Связи таблиц many-to-many one-to-one?


    @OneToOne – это когда объекту одной сущности можно сопоставить только один объект другой сущности.

    Данный тип связи встречается не часто. Для примера можно рассмотреть, то, что на некоторых сайтах пользователь может иметь только одну учетную запись.

    Нередко этот тип связей предполагает разбиение одной большой таблицы на несколько маленьких. Основная родительская таблица в этом случае продолжает содержать часто используемые данные, а дочерняя зависимая таблица обычно хранит данные, которые используются реже.

    В этом отношении первичный ключ зависимой таблицы в то же время является внешним ключом, который ссылается на первичный ключ из главной таблицы.

    Для связи один к одному в обоих классах к соответствующим полям добавляется аннотация @OneToOne. Параметр optional говорит JPA, является ли значение в этом поле обязательным или нет. Связанное поле в User объявлено с помощью аннотации @JoinColumn, параметр name которой обозначает поле в БД для создания связи. Для того, чтобы объявить сторону, которая не несет ответственности за отношения, используется атрибут mappedBy.

    Со стороны владельца к аннотации @OneToOne добавляется параметр cascade. В однонаправленных отношениях одна из сторон (и только одна) должна быть владельцем и нести ответственность за обновление связанных полей. Каскадирование позволяет указать JPA, что необходимо «сделать со связанным объектом при выполнении операции с владельцем».

    @ManyToMany – это когда к сущностям в обе стороны могут относится несколько экземпляров другой стороны.

    При этом типе связей одна строка из таблицы А может быть связана с множеством строк из таблицы В. В свою очередь одна строка из таблицы В может быть связана с множеством строк из таблицы А.

    Типичный пример - студенты и курсы: один студент может посещать несколько курсов, и соответственно на один курс могут записаться несколько студентов. Другой пример - статьи и теги: для одной статьи можно определить несколько тегов, а один тег может быть определен для нескольких статей.

    В SQL Server на уровне базы данных мы не можем установить прямую связь многие ко многим между двумя таблицами. Это делается посредством вспомогательной промежуточной таблицы. Иногда данные из этой промежуточной таблицы представляют отдельную сущность.

    Моделирование отношений «многие ко многим» с помощью POJO очень просто. Мы должны включить в оба класса коллекцию, которая содержит элементы других. После этого нам нужно пометить класс @Entity и первичный ключ @Id, чтобы сделать их правильными объектами JPA.

    Кроме того, мы должны настроить тип отношения чтобы Hibernate понял, что мы хотим создать именно двустороннее отношение нам нужно указать, какая из сторон является владельцем отношений, а какая является обратной стороной. Это делается при помощи атрибута mappedBy. Важно отметить, что указывается этот атрибут в аннотации, которая находится на противоположной стороне отношения.

    Для отношения многие ко многим любая из сторон может быть владельцем.

    В зависимости от cascade будет либо учитываться связь между сущностями для выполнения операции, либо нет. cascade=ALL – на все операции.

    cascade={PERSIST, MERGE, REMOVE, REFRESH, DETACH} – на определенные операции, те что есть в перечислении будут учитываться.

    1   ...   16   17   18   19   20   21   22   23   ...   26


    написать администратору сайта