JPA:单例实体 [英] JPA: Singleton Entity

查看:53
本文介绍了JPA:单例实体的处理方法,对大家解决问题具有一定的参考价值,需要的朋友们下面随着小编来一起学习吧!

问题描述

我有一个案例要处理一个只有一个实例的实体.

I got a case to deal with an Entity that has one and only one instance.

这种情况是对Configuration类进行建模,该类将创建一次,更新多次,并且永远不会删除.

The case is to model a Configuration class, which will be created once, updated many times and never deleted.

主要思想是,实体将像属性文件一样,但是保留在数据库中.

The main idea, is that the entity will be like the properties file but persisted in the database.

是否有关于对此类进行建模的建议,任何提示或想法?

Is there any recommandations for modeling this class, any tips or ideas ?

推荐答案

我将回答一个更普遍的问题-如何很好地实现数据库存储的应用程序配置?

I'll answer a more general question - How implement a DB stored application configuration nicely?

通常,您可能具有针对应用程序不同范围的配置,而不是一个单一的配置.IE.例如,您可能具有CarConfig,CacheConfig,BookingConfig等,还包括一些常规的AppConfig.有时您需要在开发中添加/删除属性.

In general, you may have a configuration for different scopes of your application, rather than a single all in one Configuration. I.e. for example you may have CarConfig, CacheConfig, BookingConfig, etc, including some general AppConfig as well. Sometimes you need to add/remove properties over the development.

因此,为了方便处理,我建议您为每个配置使用一个单独的单个字符串键/值配置表,而不是为每个配置都使用一个单独的表(将在下文中描述prons)..方法如下:

So to handle it conveniently, I suggest that instead having an individual table for each config (prons will be described below), you have a single string key/value Configuration table that will serve all configs. And here is how:

对于每个配置,请创建一个类似的接口:

For each config, create an interface like that:

public interface CarConfig {       
    @PropertyName("default.color")
    @DefaultValue("red")
    String getDefaultColor();

    void setDefaultColor(String color);

    @PropertyName("max.size")
    @DefaultValue(100)
    int getMaxSize();

    void setMaxSize(int size);

    ...
}

在应用程序启动时,将实例化一个配置实现,然后在整个应用程序之间共享.该实现是通过创建代理完成的.

On application startup, a single config implementation is instantiated and then shared across the application. The implementation is done by creating a proxy.

对于 getters ,代理会分析调用的方法(例如:getDefaultColor())-它从注释@PropertyName中获取属性名称.然后,它使用该属性名称查询数据库中的配置表.将该值转换为方法返回类型(如果将其作为字符串存储在表中)(如果将getMaxSize()转换为int),则返回该值.

For getters the proxy analyzes the invoked method (for ex: getDefaultColor()) - it gets the property name from the annotation @PropertyName. It then queries the configuration table in the database with this property name. The value is converted (as it's stored as a String in the table) to the method return type (in case of getMaxSize() to int) and returned.

对于设置者,代理将给定值保存到配置表中.无需重复@PropertyName-它可以从相应的getter派生.

For setters the proxy saves the given values to the configuration table. No need to duplicate @PropertyName - it can be derived from the corresponding getter.

因此,每当需要配置属性值时,都将像这样:

So whenever you need a config property value, you go like:

CarConfig carConfig = configs.get(CarConfig.class);
String defaultColor = carConfig.getDefaultColor();

为什么配置实现应该是单例并在应用程序之间共享?因为在这种情况下,您可以启用缓存-如果确保始终仅通过配置使用配置属性,则可以在启动时读取所有值并将它们存储在内存中,然后根本不查询数据库,因为没有除配置类外的任何其他更改源.设置者将更新缓存的值以及数据库配置表.

Why config implementations should be singletons and shared across the applicaton? Because in this case you can enable caching - if you ensure that config properties are always used only via your configs, you can read all the values at startup and store them in memory, and then not query the database at all, since there is no any other source of change except your config class. Setters would update the cached values as well as the database configuration table.

配置表看起来类似于:

|     key       |value |
...
|"default.color"|"blue"|
|"max.size"     |"85"  |
...

因此,在单个配置表的情况下,添加新属性仅是将getter和setter添加到类中的问题-代理将自动选择它.

So in case of a single configuration table adding a new property is just the matter of adding the getter and setter to the class - the proxy will automatically pick it up.

CUBA开源框架中使用了类似的体系结构- https://www.cuba-platform.com/.

A similar architecture is used in the CUBA open source framework - https://www.cuba-platform.com/.

相反,拥有一个用于单独配置的单独表的情况如下:

On the contrary, having a separate table for separate config has such prons as:

  • 您需要为每个配置创建一个新表;
  • 添加/删除新的config属性需要更改表架构.

这篇关于JPA:单例实体的文章就介绍到这了,希望我们推荐的答案对大家有所帮助,也希望大家多多支持IT屋!

查看全文
登录 关闭
扫码关注1秒登录
发送“验证码”获取 | 15天全站免登陆