很好不错

[Veitor]

我无意中发现了这的文章，这好是关于最近我正要寻找的关于软件代码设计中问题，包括DDD问题、业务需求中的用词概念混乱等。。

也顺便发现了你的工作与我类似差不多啊。。开发框架我们也是用的yii，并且我们公司 业务与你们有一点点小交集。。哈哈哈哈。。

希望能有更好的总结文章

[Veitor]

另外想询问一下列表和单记录查询的问题，虽然service啥也不需要做，那也要调用Repository获取数据后返回给controller吗？

[linvanda]

谢谢！ 关于列表和单记录查询这块，估计也是很多人抵触仓储模式的一个点：在这种情境下，仓储把原本简单的问题搞复杂了，远没有直接在控制器中使用AR或ORM便捷。 我个人并不赞成为了仓储模式而用仓储，为每个简单的查询（甚至就一个主键查询）在仓储中创建一个方法——这些方法就好比医药行业的各层代理，并无价值。

个人觉得可采用以下几种方式：

1. 在基仓储中实现一些常用的 CRUD 方法（可通过trait或ORM或AR），这些方法通过传参能实现比较简单的查询。这种方式实际是将仓储当作 ORM 用——但这未必不可行。
2. 直接在控制器中使用 ORM 或 AR 获取数据。（个人比较倾向 ORM，它比 AR 更具有封装性）

最近在看 Laravel 的东西，发现 Laravel 社区对Repository模式有着很鲜明的支持和反对两派。反对者（如优帆远扬的 summer）认为 Laravel 的 ORM 已足够强大，完全能胜任实际业务需要，引入仓储会带来过度设计问题。支持者认为仓储能将数据存储细节从领域中剥离——但不幸的是，他们举的例子无一能反应仓储的优势，这是因为在简单的示例程序中仓储除了造成过度设计以外别无价值，杀鸡用了牛刀。

个人认为像后台管理系统这种 CRUD 为主的，ORM 可能更合适，而对于领域业务比较复杂的必须要引入仓储模式，否则随着项目的进展，数据库结构（反映到ORM模型上）会对业务建模造成严重阻碍。

个人认为，仓储层最重要的作用并不是为了后面好替换存储层的实现——实际上，绝大多数项目都基本不会替换存储层实现。犹如控制器实现了对用例模型和领域模型的解耦与适配，仓储层实现了对领域模型和数据库模型的解耦与适配，通过数据库模型建立领域模型。ORM最大的问题在于其是直接对数据库结构的反映，代表着数据库模型，在复杂业务领域项目中，一个数据表往往有几十个字段，如果直接用 ORM，那也就是在这一个 ORM Model 上操作着几十个属性，这既不符合 OOD，更不符合 DDD。

搞清楚了仓储的真正作用，也就不会再纠结要不要用仓储了，而应该去思考什么情景下该用仓储，什么时候该用ORM Model，什么样的项目该是ORM为主，什么样的项目该 Repository 为主。ORM 和 Repository是可以一起用的。

另外还有个可能的困扰是，如果我现在直接在控制器中用 ORM / Repository 获取数据，后面需求变化了岂不是又要去改动，而且可能还会将业务逻辑暴露在控制器中？ 个人认为，对于简单的查询逻辑，ORM是可以胜任的，至于后面需求变化，当一个ORM模型为了满足业务需求而做了明显不属于它职责的事时，就要考虑把业务搬到实体中了，而为了从持久化层中获取该实体实例（一般通过ORM或AR代理来获取），也就需要仓储上场了。

上面只是说了下个人的想法，不一定都对，希望能有参考价值。