Я размышлял об архитектуре своего сервера в течение нескольких дней с тех пор, как разрабатывал свой первый 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 помогает мне игнорировать все создание таблиц, но, возможно, это не очень хорошая практика, и я должен разделить ее на две разные сущности.