接下来这篇我们要来谈谈,我个人觉得很重要的 UnitOfWork,这个东西很多人知道要,但是应该也不少公司没在实作,因为没有发生问题,就一切平安呢 ~
Maintains a list of objects affected by a business transaction and coordinates the writing out of changes and the resolution of concurrency problems.
事实上你几乎可以想成是资料库 transaction 的概念,只是某些方面它是以将 db 的概念移除,想要以 domain 层级来达成 transaction 的事情。
追踪所有被新增、修改、删除的 Domin Model instance,并在 commit 时一次送出这些修改。
我们到了今天总共学到了不少层级加 pattern,那我们是要以那个层级中的那个部份为单位呢 ? service、domain model、row data gateway、table data gateway、repository、model ( active record )、data mapper 呢 ?
说实话我单看书中的范例,它是在 service 中注册,然後以 data mapper 为单位。
class EditAlbumScript...
public static void updateTitle(Long albumId, String title) {
UnitOfWork.newCurrent();
Mapper mapper = MapperRegistry.getMapper(Album.class);
Album album = (Album) mapper.find(albumId); album.setTitle(title);
UnitOfWork.getCurrent().commit();
}
但是又有想到是以 repository 为单位的范例,所以我个人的理解应该是 :
我觉得应该是以 repository 操作为单位来运行,因为事务可以想成是很多业务任务所组成,他应该是接近 domain layer 那的。
而至於书中范例为什麽会是 data mapper 呢 ? 我觉得有机率是章节编排的问题,因为在谈到 unitOfWork 时,还没谈到 repository ~ 哈哈。
之前我一直在思考资料库的 transaction 在 3-Tier 到底是该在那处理,与如何处理,看起来 unitOfwork 就是答案。
资料库的事务,要如何在 3-Tier 放在合适的位置,我之前一直在思考这件事情,而且以前写程序码时也很常将所有需要事务的操作,都写在 dao 层的一个方法中,但我之前怎麽想都觉得怪怪的呢。
而 unitOfwork 有点像是将事务操作,包含资料库的部份封装在一起,这样在往上想一下,它会不会是放在任务层级都可以呢 ?
这里事实上还有个衍伸讨论,一直想找时间写 :
MonogoDB 是如何实现事务呢 ? 而它有符合 ACID 吗 ?
<<: Day21:今天来聊一下Azure Sentinel 介绍
>>: 那些被忽略但很好用的 Web API / ResizeObserver
单纯纪录自己用的 Guzzle Request 模板 简单版 use GuzzleHttp\Clie...
Functions 紧接着,我们就要来介绍函数了!写函数可以让我们的程序码更简洁明了也更有效率,因此...
1.res.send()和 res.end()的差别 (1)res.write + res.end ...
Abstract 我们前面已经讨论了相当多种取得Bean的方法,如:自动注入(@Autowired、...
useLocation 函数是当 URL 网址改变时useState()会返回一个新的包含有关目前U...