这不就是产品给我留的数学作业！

用UOW模式实现Repository

看了《无法实施富领域模型的罪魁祸首找到了》这一篇文章后，很多人都会问这种Repository是这么实现的。这种Repository的实现背后用了一个叫做 “Unit of Work (UOW)”的模式：

Maintains a list of objects affected by a business transaction and coordinates the writing out of changes and the resolution of concurrency problems.Unit of Work --Martin Fowler

UOW模式是在业务用例的操作中跟踪对象的所有更改(增加、删除和更新)，并将所有更改的对象保存在一个列表中。在业务用例的终点，通过事务，一次性提交所有更改，以确保数据的完整性和有效性。总而言之，UOW协调这些对象的持久化及并发问题。
 

而当我们有依赖的时候，需要添加上 classpath，即将依赖添加到编译的路径中。而对于一些非 .jar 类型的依赖而言，如 .war，构建工具还要支持对他们的解析。因此，整体的过程就是：

1. 判断是否存在本地的依赖，如果没有的话，从远程获取。如果有依赖冲突的话，解决这些冲突，或者报错。
2. 获取依赖后，根据需要对依赖进行处理。如 Android 中的 aar 包的解压等。
3. 结合依赖，对源码进行编译
4. 将所需要的 Java Resources 从依赖的 Jar 拷贝到指定目录
5. 打包构建后的产物到一个新的 jar 包中

这些只是表面上的一些工作。而为了更好地表述这个过程，需要抽象出一个 task 的概念，在这个概念里，一个 task 有输入和输出。如

1. 解析依赖里。它的输出是 build.gradle 文件，输出是处理完的依赖路径。
2. 编译任务里。它的输入是源码，输出是 .class 文件。
3. 打包任务里。它的输入是一堆文件夹或者文件，输出是一个 .jar 包。
4. ……

于是，在有了这些基础之后，为了加快构建，还需要缓存的机制。它对输入和输出进行计算，当两者发生变化的时候，再进行编译。否则就跳过这个任务。

而这些只是核心功能，在非核心的功能区里，还有诸如于 SDK 版本、多输入多输出的变体等等。

IDE 与构建系统

在那篇《编程语言的 IDE 支持》中，我们已经介绍了编程语言所需要的 IDE 功能，诸如于：

1. 语法高亮
2. 子系统关联与集成
3. 跳转与引用分析
4. 智能感知
5. 重构
6. 快速修复
7. 结构化视图
8. ……

在这篇文章中，大概再回顾一下它与构建系统之间的关系。IDE 与构建系统一般会存在这种关联：

1. 解析构建系统中的任务。如 Gradle 提供的 task，又或者是 package.json 中的 scripts，并将它们显式地展示出来，如 IDEA 中的 line marker，又或者是独立的 Gradle pannel。
2. 执行构建任务。即在 IDE 中的 UI 与构建命令相绑定，典型的如 IDEA 中的 Android 应用的构建。
3. 动态修改构建系统(可选)。如 IDEA 中的更新依赖版本，它依赖于解析构建系统的 DSL，并更新对应的 DSL。

（编辑：宜春站长网）

【声明】本站内容均来自网络，其相关言论仅代表作者个人观点，不代表本站立场。若无意侵犯到您的权利，请及时与联系站长删除相关内容!