Разработка слоев API-интерфейса Spring Boot RESTful и отображение его сущностей - PullRequest
0 голосов
/ 25 апреля 2020

Я размышлял об архитектуре своего сервера в течение нескольких дней с тех пор, как разрабатывал свой первый RESTful API с нуля, с помощью Spring Boot. Я использую Hibernate, и я создал несколько сущностей и их взаимосвязей, используя аннотации Hibernate / JPA, однако я не уверен, стоит ли мне использовать эти сущности в качестве бизнес-моделей, поскольку они «грязные» с дополнительными полями, которые рекомендовал бы Hibernate.

Это моя предварительная многоуровневая архитектура REST API

Это пример, взятый непосредственно из документации Hibernate.

@Entity(name = "Person")
public static class Person implements Serializable {

    @Id
    @GeneratedValue
    private Long id;

    @NaturalId
    private String registrationNumber;

    @OneToMany(
        mappedBy = "person",
        cascade = CascadeType.ALL,
        orphanRemoval = true
    )
    private List<PersonAddress> addresses = new ArrayList<>();

    // ...

    public void addAddress(Address address) {
        PersonAddress personAddress = new PersonAddress( this, address );
        addresses.add( personAddress );
        address.getOwners().add( personAddress );
    }

    public void removeAddress(Address address) {
        PersonAddress personAddress = new PersonAddress( this, address );
        address.getOwners().remove( personAddress );
        addresses.remove( personAddress );
        personAddress.setPerson( null );
        personAddress.setAddress( null );
    }
}

@Entity(name = "PersonAddress")
public static class PersonAddress implements Serializable {

    @Id
    @ManyToOne
    private Person person;

    @Id
    @ManyToOne
    private Address address;

    // ...
}

@Entity(name = "Address")
public static class Address implements Serializable {

    @Id
    @GeneratedValue
    private Long id;

    private String street;

    @Column(name = "`number`")
    private String number;

    private String postalCode;

    @OneToMany(
        mappedBy = "address",
        cascade = CascadeType.ALL,
        orphanRemoval = true
    )
    private List<PersonAddress> owners = new ArrayList<>();

    // ....
}

Что я имею в виду, если я если бы сделать диаграмму классов, она бы не выглядела точно так же, как эти объекты, из-за условий, которые вы должны выполнить sh для Hibernate, чтобы он мог отобразить их в таблицы с ORM. Например, в гипотетической диаграмме классов Person будет иметь список Address, а не список PersonAddress, как предлагает Hibernate в этом случае (для отображения производительности).

У меня вопрос: следует разделить модель Person на две отдельные сущности, одну для уровня бизнес-логики c (сервисы) и одну для уровня доступа к данным (репозитории). Лично я не думаю, что это проблема, потому что Hibernate помогает мне игнорировать все создание таблиц, но, возможно, это не очень хорошая практика, и я должен разделить ее на две разные сущности.

Ответы [ 2 ]

0 голосов
/ 26 апреля 2020

То, на что вы ссылаетесь - это довольно частое разделение между моделью персистентности и моделью бизнес / домен. Люди часто называют это подходом DTO. Этот подход имеет много преимуществ, и если вы правильно его реализуете, у него почти нет недостатков.

Эффективная реализация может быть реализована с помощью Blaze-Persistence Entity-Views библиотеки поверх JPA / Hibernate, которая будет обрабатывать все выборки для вас прозрачно. Взгляните на пружинную интеграцию данных , которая позволяет очень быстро начать работу, или попробуйте пример проекта с помощью архетипа , чтобы почувствовать преимущества.

0 голосов
/ 26 апреля 2020

Обычно я использую API-модель и Entity-модель. Модель API используется для обмена данными между службами, а объект сущности используется для сохранения данных. Это делает вашу архитектуру более гибкой. Если что-то в вашем busineslogi c изменяется, сущность не затрагивается автоматически. Также иногда вы получаете данные от клиента и не хотите раскрывать весь объект базы данных. Таким образом, вы можете предоставить только те поля, которые вам нужны, и заполнить все остальные в объекте сущности. Это также рекомендуется stati c sonaqube для анализа кода.

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