现代移动互联网应用设计模式

1.个人感觉有 Service 就好，不太清楚 Repository 的必要性；
2.如果Web端也是前后端分离的话，Presenter－》View 这条线也省了。

@MrJing

1. Repository 模式主要思想是建立一个数据操作代理层，把controller里的数据操作剥离出来，这样做有几个好处：

把数据处理逻辑分离使得代码更容易维护
数据处理逻辑和业务逻辑分离，可以对这两个代码分别进行测试
减少代码重复
降低代码出错的几率
让controller代码的可读性大大提高

https://segmentfault.com/a/119000000487593...
https://bosnadev.com/2015/03/07/using-repo...
http://laravelacademy.org/post/3063.html

2. Presenter一般是针对Web 这条线的

@braveTM 反正Service 够用了，Service一样可以把controller里的数据操作剥离出来啊。

我喜欢这种写法： https://github.com/ruby-china/homeland/blo...

干净利落，简单易懂，最重要，写出来舒服

KISS - Keep it simple and stupid

@braveTM Repository 真是一个争议很大的玩意儿。逻辑放 Service，再搞一层 Repository 啰嗦。是为了什么需要引入数据操作代理层，担心将来换数据存储吗？

@Summer 感觉 Model 里面写业务逻辑也不好看。里面单纯就一些关联查询的定义，还有 Scope 范围查询就好。

@MrJing 大 rails 纵横天下无数年，没听过他们需要用 repository 的，自己用着喜欢就好。

我的选型的标准是简单、编程愉悦感强。这才是最重要的，搞一堆 repository 的话，我可能就跑去写 rails 了。

@MrJing repository 在大多数情况下，在我看来就是过度设计。

类似这篇文章：https://segmentfault.com/a/119000000487593... 说的，学习 Repository Pattern 的理由如以下：

• 把数据处理逻辑分离使得代码更容易维护
• 数据处理逻辑和业务逻辑分离，可以对这两个代码分别进行测试
• 减少代码重复
• 降低代码出错的几率
• 让controller代码的可读性大大提高

那我就想问了：使用 Model 无法进行上面做的东西？

在我看来最好的方式还是这种： https://github.com/ruby-china/homeland/blo...

.
.
.
class Topic < ApplicationRecord
  include MarkdownBody
  include SoftDelete
  include Mentionable
  include Closeable
  include Searchable
  include MentionTopic
.
.
.

@MrJing 在 PHP 中，可以模拟上面方法，把逻辑接近的方法，放到一个 Trait 里。举例搜索相关的方法放到：Searchable Trait 里，这样 Model 就不会爆掉，并且可读性很强。

调用的时候：

$topic->search();

读起来爽，写起来也爽

@Summer 如果 Searchable 之类的和 SoftDelete 一样，能用统一可复用的代码实现，那用 Trait 挺爽的。如果只能单独对 Topic 业务实现，其实是把这一搓代码放到了另外的地方（放哪里都行），让 Model 显得不肥。

个人比较喜欢拆分成repository和service两个部分，通常一个repository对应一个model，若是当业务查询逻辑太多可以拆分成多个repository，而很难拆成多个model，多个repository封装成一个service块的话会十分便利和简洁。