为什么每个实体都应该有单独的MyBatis映射器?

时间:2018-08-10 13:25:29

标签: java structure mybatis

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

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映射器作为惯例,如果对我而言,数据库比实体更重要,那么每个数据库连接都具有一个映射器是可接受的设计方式吗?

2 个答案:

答案 0 :(得分:2)

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

基本上,映射器的结构反映了应用程序的结构。通常,每个module都有一个映射器,其中包含module的广泛定义。它不一定意味着每个类都有映射器。如果可以按数据库类型将应用程序中的代码分开,则每种数据库类型都可以使用映射器。

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

答案 1 :(得分:0)

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