首页 » PHP教程 » phpslides技巧_spring data jpa 100 steps 1storm 常用设计模式

phpslides技巧_spring data jpa 100 steps 1storm 常用设计模式

访客 2024-11-20 0

扫一扫用手机浏览

文章目录 [+]

平时写业务代码中,最常见的事情可能便是数据库的 CRUD 操作了,可以这么负任务的说:互联网运用,实质便是在进行 CRUD 操作,唯一不同的便是业务条件不同,繁芜度则来自于你要同时更新、查询的库表有多少。

刚开始入行的时候,我用的是 php,当时自己大略的封装了一个 Abstract Dao,然后基本每新建一个表就新建一个类就去继续这个 Abstract Dao,如下所示:

phpslides技巧_spring data jpa 100 steps 1storm 常用设计模式

但是这种做法带来的问题便是后期随着项目表的增加,会创造有太多的类了,而且这些类基本都只是去继续 BaseDao,然后便是每个类都去要写一大推 findByXXX 的接口,那有没有什么办法能一劳永逸呢?避免这种呆板的代码呢?

phpslides技巧_spring data jpa 100 steps 1storm 常用设计模式
(图片来自网络侵删)

先别焦急办理方法,我们先来来点理论根本的,看下常见的 orm 设计模式。

Row Data Gateway

Row Data Gateway

一个工具扮演的角色就像是数据库中单行记录的网关(Gateway)

每个工具对应数据库中的一行:

利用

底层实现

Table Data Gateway

扮演着数据库表的网关角色(Gateway), 一个工具处理了表中所有的行记录.

此处 DAO 实现了 CURD 操作,读一样平常会比较繁芜,是一系列 Finders,

insert 方法

update 方法

Finder 方法

利用魔术方法 __call() 来实现这些魔术般的 finders

http://www.php.net/manual/en/language.oop5.overloading.php#object.call.

Active Record

封装了表中的单行记录,除此之外加上了领域逻辑.

Active Record = Row Data Gateway + Domain Logic

我们会直接将一些领域逻辑写到 dao 中。

Data Mapper

Data Mapper 让 dao 和业务逻辑彼此独立,通过 Data Mapper 来将内存中的工具和数据库中的记录联系起来。

将内存中的数据映射到数据库中,同时保持着彼此之间的解耦。

Identity Map

Identity Map 在 Data Mapper 之上更进了一步,不仅掩护了映射关系,而且对数据库进行了缓存,担保同一个工具的要求不会重复去数据库中读取,减少 io,同时担保工具发生变革后,能同步到数据库中。

担保每个工具只会从数据库中加载一次,一旦加载进来,将其保存到一个 map 中

Object Relational Mapping

先容完上面的常用设计模式后,我们来看一个观点:ORM,工具关系映射。

ORM 一样平常认为是实现上面各种设计模式的一个工具,并且能很方便的处理工具之间的关系,而常见的工具关系有:

One-To-One;

One-To-Many;

Many-To-Many.

有了 orm 之后,在更进一步的 Domain-Driven Design 中,orm 可以说是再进一步,在 ddd 中常见的几个观点有:

Entities:可以通过 id 进行区分的工具 entity

Value Objects:直接通过值来分区,无 id 的工具

为了我们方便的处理 Entity,就涌现了 Repository。

Repository Pattern

Repository 折衷了领域工具和数据映射层的关系,扮演着内存中领域工具凑集( in-memory domain object collection)的角色。

工具可以被添加进 Repository,同样的也能从 Repository 中移除,从这个角度讲,Repository 有点类似于凑集的观点,其内部封装了工具和数据库记录之间的映射关系,Repository 供应了 persistence 的一个更面向工具的视角。

Repository 同时很好的办理了领域工具和数据映射层之间的耦合关系,充分的分离的关注点,领域工具和数据映射层可以独自的开拓,蜕变。

Specification Pattern

在 Repository 中,我们不得不面对各种各样的查询条件,于是就有了 Specification 模式,帮助我们办理查询条件多的问题:

Specification pattern 可以将业务规则建模为独立的工具,其紧张思想是关注一个工具的问题,可以通过 isSatisfiedBy() 来回答:

Repository ♥ Specification

将 Repository ♥ Specification 两者组合起来:

在业务层复用 specifications:

这是 jpa 的第一篇,你的鼓励是我连续写下去的动力,期待我们共同进步。
欢迎关注头条号,这个时期,每个人都是超级个体!
关注我,一起发展!

参考

https://github.com/willdurand-edu/php-slides/blob/master/src/common/09_databases.md

相关文章