为什么每个实体都应该有单独的 MyBatis 映射器?
Why should there be separate MyBatis mappers for each entity?
我正在开发一个使用 MyBatis 注释和映射器接口的小型应用程序。我在MyBatis上看到的所有例子,包括官网,都为每个实体创建了一个单独的mapperclass。我有两个实体,Foo
和 Bar
,以及两个分别包含这些实体的数据库。所以目前我的项目结构的一部分是这样的:
model
├── bar
│ ├── Bar.java
│ ├── DB1BarMapper.java
│ └── DB2BarMapper.java
└── foo
├── Foo.java
├── DB1FooMapper.java
└── DB2FooMapper.java
在我的项目中,Foo
和 Bar
对象的处理大致相同,但数据库在逻辑上具有不同的功能。我正在考虑更改我的项目设计,我将按数据库对映射器进行分组,然后可以像这样简化结构:
model_new
├── Bar.java
├── Foo.java
├── DB1Mapper.java
└── DB2Mapper.java
在这里,DB 映射器将包含访问 Foo
和 Bar
实体(以及 return 对应的 POJO)的方法。
据我所知,这在编程方面是有效的,因为映射器被添加到数据库配置中,并且因为映射器本身不引用特定对象,而不是 return 从方法中调用它们.
我试图研究这是否是一种可接受的做法,但我没有找到任何关于为什么这是习俗的问题或文章,MyBatis 站点也没有解决这个问题。我最好的猜测是它与 DAO 模式有关,但在我的案例中我没有看到以这种方式使用它的任何优势。
所以我的问题是,为什么每个实体都有一个单独的 MyBatis 映射器是自定义的,如果对我来说数据库比实体更重要,那么每个数据库连接都有一个映射器在设计上是否可以接受?
为每个数据库的每个实体保留一个映射器更为明智。例如:如果在某个时候你改变了你的 FOO 映射的方式,那么你只改变那个实体映射器而不触及另一个,如果你想 add/delete 一个实体 to/from 映射也是如此。您将拥有更清晰、更易于维护的代码。
为多个实体使用一个映射器并没有错。映射器是一种具有 DAO 层逻辑的模块。用于将其他代码拆分为模块的相同标准也适用于映射器,即:一个映射器中的事物应具有高内聚性,而不同映射器中的事物应具有低耦合性。
映射器的结构基本上反映了应用程序的结构。正如大多数情况下,每个 module
都有一个映射器,其中包含 module
的广泛定义。它不一定意味着每个 class 的映射器。如果按数据库类型分隔应用程序中的代码是有意义的,它可能是每个数据库类型的映射器。
每个实体映射器 class 流行的原因是每个 class 映射器是拆分映射器的自然方式,因为实体 class 是应用程序的一个自然模块。但情况并非总是如此,也不总是最方便的拆分方式。在许多情况下,每个 aggregate 有一个映射器是有意义的,它是一个域对象集群的映射器,可以被视为一个 unit/module.
我正在开发一个使用 MyBatis 注释和映射器接口的小型应用程序。我在MyBatis上看到的所有例子,包括官网,都为每个实体创建了一个单独的mapperclass。我有两个实体,Foo
和 Bar
,以及两个分别包含这些实体的数据库。所以目前我的项目结构的一部分是这样的:
model
├── bar
│ ├── Bar.java
│ ├── DB1BarMapper.java
│ └── DB2BarMapper.java
└── foo
├── Foo.java
├── DB1FooMapper.java
└── DB2FooMapper.java
在我的项目中,Foo
和 Bar
对象的处理大致相同,但数据库在逻辑上具有不同的功能。我正在考虑更改我的项目设计,我将按数据库对映射器进行分组,然后可以像这样简化结构:
model_new
├── Bar.java
├── Foo.java
├── DB1Mapper.java
└── DB2Mapper.java
在这里,DB 映射器将包含访问 Foo
和 Bar
实体(以及 return 对应的 POJO)的方法。
据我所知,这在编程方面是有效的,因为映射器被添加到数据库配置中,并且因为映射器本身不引用特定对象,而不是 return 从方法中调用它们.
我试图研究这是否是一种可接受的做法,但我没有找到任何关于为什么这是习俗的问题或文章,MyBatis 站点也没有解决这个问题。我最好的猜测是它与 DAO 模式有关,但在我的案例中我没有看到以这种方式使用它的任何优势。
所以我的问题是,为什么每个实体都有一个单独的 MyBatis 映射器是自定义的,如果对我来说数据库比实体更重要,那么每个数据库连接都有一个映射器在设计上是否可以接受?
为每个数据库的每个实体保留一个映射器更为明智。例如:如果在某个时候你改变了你的 FOO 映射的方式,那么你只改变那个实体映射器而不触及另一个,如果你想 add/delete 一个实体 to/from 映射也是如此。您将拥有更清晰、更易于维护的代码。
为多个实体使用一个映射器并没有错。映射器是一种具有 DAO 层逻辑的模块。用于将其他代码拆分为模块的相同标准也适用于映射器,即:一个映射器中的事物应具有高内聚性,而不同映射器中的事物应具有低耦合性。
映射器的结构基本上反映了应用程序的结构。正如大多数情况下,每个 module
都有一个映射器,其中包含 module
的广泛定义。它不一定意味着每个 class 的映射器。如果按数据库类型分隔应用程序中的代码是有意义的,它可能是每个数据库类型的映射器。
每个实体映射器 class 流行的原因是每个 class 映射器是拆分映射器的自然方式,因为实体 class 是应用程序的一个自然模块。但情况并非总是如此,也不总是最方便的拆分方式。在许多情况下,每个 aggregate 有一个映射器是有意义的,它是一个域对象集群的映射器,可以被视为一个 unit/module.