Недостатки создания базового класса для JPA-объекта (объект типа домена) в общей библиотеке - PullRequest
Новая
       13

Недостатки создания базового класса для JPA-объекта (объект типа домена) в общей библиотеке

0 голосов
/ 15 января 2020

Я опытный. net разработчик недавно перешел на java разработку. Я работаю на микро-сервис, используя весеннюю загрузку / облако. Для своей работы я создал общий jar (разделяемую библиотеку), в котором я размещаю те функциональные возможности и вспомогательные методы, которые должны повторно использоваться в различных микро-сервисах.

Я вызываю разделяемую библиотеку в своем приложении для каждой весенней загрузки, добавляя в нее свой файл pom. Все это прекрасно работает, и я могу использовать разделяемую библиотеку в каждом своем микро-сервисе как предполагалось.

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

Поскольку в большинстве микро-сервисов требуется несколько общих полей, я подумал о том, чтобы создать базовый класс Entity в моем общем jar (разделяемой библиотеке) и сделать так, чтобы сущности в моих микро-сервисах наследовали базовый класс Entity.

Это базовый класс Entity, который я создал в моей общей библиотеке 

package com.microservice.xcloud.common.entity;

import javax.persistence.Column;
import javax.persistence.GeneratedValue;
import javax.persistence.GenerationType;
import javax.persistence.Id;
import javax.persistence.MappedSuperclass;

@MappedSuperclass
public class BaseEntity {

    @Id
    @GeneratedValue(strategy=GenerationType.AUTO)
    Long id;

    ...

    @Column(nullable = true , name = "isDeleted")
    private boolean isDeleted;

    public Long getId() {
        return id;
    }

    public void setId(Long id) {
        this.id = id;
    }
    ...

    public boolean isDeleted() {
        return isDeleted;
    }

    public void setDeleted(boolean isDeleted) {
        this.isDeleted = isDeleted;
    }   

}

Теперь в моих разных микро-сервисах я наследую от этого класса, чтобы иметь эти поля, не записывая их снова и снова. (DRY принцип).

Я использовал этот способ, работая с. net и EF, и обнаружил, что он работает отлично. Я бы поместил базовую сущность в разделяемую dll и унаследовал от нее в моем приложении. Поэтому я использовал одно и то же для java, и я сделал это в классе Entity моего приложения для микросервиса. 

package com.microservice.xcloud.companyservice.entity;



import javax.persistence.Column;
import javax.persistence.Entity;
import javax.persistence.Table;

import com.microservice.xcloud.common.entity.BaseEntity;

@Entity
@Table(name = "companymaster")
public class CompanyMaster extends BaseEntity{



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

    @Column(nullable = true , name = "description")
    private String description;



    public String getCompanyName() {
        return companyName;
    }

    public void setCompanyName(String companyName) {
        this.companyName = companyName;
    }

    public String getDescription() {
        return description;
    }

    public void setDescription(String description) {
        this.description = description;
    }

    public CompanyMaster() {
        super();

    }
}

Обратите внимание, что у меня есть два разных приложения, 1. Общая библиотека java называется общим 2. Приложение микро-службы под названием company-service, использующее разделяемую библиотеку через pom 

<!-- Shared library -->
<dependency>
    <groupId>com.microservice.xcloud</groupId>
    <artifactId>common</artifactId>
    <version>${project.version}</version>
</dependency>

Мне сказали, что это плохая архитектура, и ее не следует делать таким образом. Также мне сказали, что это приведет к двум отдельным вызовам в db, один для базовой сущности совместно используемой библиотеки и другой для класса сущности микросервиса. Это то, о чем я никогда не слышал. net мир. Поскольку я новичок в java, мне нужен ваш совет эксперта. Насколько я знаю, в мире. net, поскольку разделяемая библиотека - это dll, и она не может работать отдельно и должна быть присоединена к приложению, это совершенно не обсуждается. Моя общая библиотека (созданная с использованием весенней загрузки) не имеет основного метода и, следовательно, должна быть присоединена к вызывающему микро-сервису, например, к jar-файлу типа dll, прикрепленному к je-файлу exe-типа.

Благодарю вас за ваш опыт и внимание

1 Ответ

0 голосов
/ 15 января 2020

Я не вижу никаких проблем, поскольку у вашей сущности нет полей, которые могли бы перемещаться к другим сущностям (т.е. нет поля, сопоставленного с @OneToMany / @ManyToOne), поэтому сопоставлены все его поля к той же таблице БД, и нет никаких причин, по которым это приведет к отдельным вызовам базы данных для загрузки сущности.

также предоставляет базовую сущность AbstractAuditable, которую разработчик может выбрать для ее использования, а не для создания самостоятельно (хотя ее использование приведет к увеличению соединение сущности с Spring Data), поэтому создание базового сущности в качестве отдельного общего JAR-файла и использование других проектов очень распространено. Это даже хорошая практика, если в вашей компании есть некоторые правила, согласно которым все сущности должны иметь определенный набор полей, таких как id, createBy et c. главным образом потому, что он может сделать коды DRY, как вы сказали.

...