【问题标题】:Why should there be separate MyBatis mappers for each entity?为什么每个实体都应该有单独的 MyBatis 映射器?
【发布时间】:2018-08-10 13:25:28
【问题描述】:

我正在开发一个使用 MyBatis 注释和映射器接口的小型应用程序。在我在 MyBatis 上看到的所有示例中,包括官方网站,都为每个实体创建了一个单独的映射器类。我有两个实体,FooBar,以及两个分别包含这些实体的数据库。所以目前我的项目结构的一部分看起来像这样:

model
├── bar
│   ├── Bar.java
│   ├── DB1BarMapper.java
│   └── DB2BarMapper.java
└── foo
    ├── Foo.java
    ├── DB1FooMapper.java
    └── DB2FooMapper.java

在我的项目中,FooBar 对象的处理方式或多或少相同,但数据库在逻辑上具有不同的功能。我正在考虑改变我的项目设计,我将按数据库对映射器进行分组,然后结构可以简化如下:

model_new
├── Bar.java
├── Foo.java
├── DB1Mapper.java
└── DB2Mapper.java

在这里,数据库映射器将包含访问FooBar 实体(并返回相应的POJO)的方法。

据我了解,这在编程方面是有效的,因为映射器被添加到数据库配置中,而且映射器本身不引用特定对象,而是从方法返回它们。

我试图研究这是否是一种可接受的做法,但我没有找到任何关于为什么这是习惯的问题或文章,MyBatis 网站也没有解决这个问题。我最好的猜测是它与 DAO 模式有关,但在我的情况下,我认为以这种方式使用它没有任何优势。

所以我的问题是,为什么每个实体都有一个单独的 MyBatis 映射器是自定义的,如果对我来说,数据库比实体更重要,那么每个数据库连接有一个映射器在设计上是否可以接受?

【问题讨论】:

  • 您可以为 DB1 和 DB2 创建一个通用超类,然后为 Foo 和 Bar 创建小的特定子类,这些子类扩展了上述超类

标签: java structure mybatis


【解决方案1】:

为多个实体使用一个映射器并没有错。映射器是一种具有 DAO 层逻辑的模块。与将其他代码拆分为模块的相同标准也适用于映射器,即:一个映射器中的事物应具有高内聚性,而不同映射器中的事物应具有低耦合性。

基本上映射器的结构反映了应用程序的结构。与大多数情况一样,每个module 都有一个映射器,具有module 的广泛定义。这并不一定意味着每个类的映射器。如果将应用程序中的代码按数据库类型分开是有意义的,它可能是每个数据库类型的映射器。

每个实体类的映射器之所以受欢迎,是因为每个类的映射器是拆分映射器的自然方式,因为实体类是应用程序的自然模块。但情况并非总是如此,也并非总是最方便的拆分方式。在许多情况下,每个aggregate 都有一个映射器是有意义的,它是一个用于可以被视为一个单元/模块的域对象集群的映射器。

【讨论】:

    【解决方案2】:

    为每个数据库的每个实体保留一个映射器更为明智。 EX:如果在某些时候您更改了 FOO 的映射方式,那么您仅更改该实体映射器而不触及另一个,如果您想在映射中添加/删除一个实体也是如此。您将拥有更清晰、更易于维护的代码。

    【讨论】:

      猜你喜欢
      • 2019-10-26
      • 1970-01-01
      • 2021-08-27
      • 1970-01-01
      • 1970-01-01
      • 1970-01-01
      • 1970-01-01
      • 1970-01-01
      • 2020-12-12
      相关资源
      最近更新 更多