认识达内从这里开始

分层架构开发是目前大多数软件编程开发程序员都在学习与应用的一种编程开发技术，而本文我们就通过案例分析来简单了解一下，分层架构仓储应用分析。

从分层上来说，仓储处于业务边界处，连接业务层和存储层(基础设施层)。仓储是懂领域语言的(但不代表要在里面实现具体的业务逻辑)，另一方面它也懂持久化相关工作。

我们先看看集合。集合里面装着一组同质(同类)元素(对象)，拥有添加(add)、移除(remove)。注意，集合并没有modify和save操作，因为我们获取的是集合中对象的引用，当对象状态发生变化时，集合中的那个对象是同步变化的。

面向集合的仓储实现严格模拟集合的行为，拥有add、remove方法，没有save方法，因为我们获取的是集合对象引用，其状态的改变会立即反应到集合中(具体实现上内部会采用读时复制或写时复制机制来跟踪实体状态的变化)。面向持久化的仓储除了和前者一样拥有add和remove方法，还有save方法，即外界需要显示的调用仓储的save(Object)方法来保存实体状态的变更(实际中往往add也被合并到save方法中)。

无论是面向集合还是面向持久化，都要求我们以集合的方式来使用仓储——这也正是仓储和数据访问对象DAO不同之处。仓储是面向领域对象的，它的职责是将领域对象(聚合)持久化到基础设施中，以及从基础设施中获取数据并还原成领域对象返回。DAO是面向数据表的，一般和数据表一一对应，并自带CRUD方法——和集合的add、remove方法不同，DAO的CRUD对应的是数据库的CRUD操作的。

我们可以恰如其名地理解“仓储”。它是一个仓库，我们将货物交给仓库管理员，由仓库保管，至于怎样保管是仓库内部的事了。另外我们根据货物编号(以及其他过滤条件)向仓库管理员索要指定的货物，至于怎样将货物从仓库中取出是仓库内部的事，仓库可以自己决定如何保管货物(如为了节约空间可能会将货物拆卸分类存放)，但仓库必须保证取出来的货物和当时放进去的是一模一样的(除非不可抗原因如过期了)。

我们现在的仓储使用面临一些问题。大的问题是仓储中包含了大量的业务逻辑——这也正是面向数据库编程所导致的结果，我们的思维直接和数据库打交道，而仓储无疑是我们所编写的离数据库近的东西了。我们程序中并没有领域对象(实体)，因而和仓储打交道的是毫无业务含义的数组。

OO是一种思想，一种思考问题的方式，而在实现上，则应“合理的才是存在的”，不可机械搬套。

不是说PHP的数组不可以用，而是说数组应该作为“数组”来使用，而不是万金油。用数组代替对象结构，会造成很大的维护复杂性。)

如果仓储本身包含了大量业务逻辑，还不如使用传统的(也是主流框架自带的)Model，至少它有“模型”的概念(虽然是面向数据表的)，而此处的仓储则是“四不像”。

目前的仓储使用的另一个严重问题是在仓储中实现事务。从仓储的描述来看，它只是担任存与取的职责，何以跟事务挂钩?这还是由面向数据库编程的思维导致的。当提及事务，我们先想到的是关系型数据库中的事务，并且理所当然地认为此事务即彼事务，那么既然是数据库的东西，当然要放到仓储层了。

什么是事务?事务是指需保证一项任务的原子性，任务中的各项操作要么全部成功，要么全部失败(撤销掉)。事务本身和数据库没半毛钱关系。我们说银行转账业务需具有事务性，我们指的是这项业务，而不是业务背后的存储技术。数据库层面的事务是将“事务”这个概念应用到数据库这个具体领域而言的，具体说来是事务中的一系列写操作要么全部成功，要么全部失败。我们真正需要关注的显然是业务层的事务性，业务层不具有事务性了，存储层的事务又有何意义?数据库事务是对业务事务的低层技术支撑，改天我们不用关系型数据库了，难道业务就不能有事务性了?

仓储和实体的操作都是细粒度的，无法保证整体的事务性，也不应当知晓事务的存在。

事务应当放在那个能代表单一完整任务的方法中(如应用服务中)。

将事务放在仓储层，不可避免地会将业务逻辑带入仓储中。

【免责声明】本文系本网编辑部分转载，转载目的在于传递更多信息，并不代表本网赞同其观点和对其真实性负责。如涉及作品内容、版权和其它问题，请在30日内与管理员联系，我们会予以更改或删除相关文章，以保证您的权益!更多内容请加danei0707学习了解。欢迎关注“达内在线”参与分销，赚更多好礼。