依赖反转相关 about blog_comment

[nlimpid]

Logic层使用了这个抽象的interface，应该有它的所有权，放Logic层，而repo只是实现这个interface的细节。

另外这个MVC分层的术语也太多了吧，Repo/Dao/Protocol/Logic/Controller/Model...

[cch123]

@nlimpid

1. 没错，应该在 logic 里
2. 工程领域发声的人比较多，比如 martin fowler，uncle bob 和 ddd 社区里的一堆人，相似的概念他们造了很多不一样的词

Repo 和 Dao(这两个的细微差别在 IDDD 一书里有说明，但实际编码的时候大多数公司都是乱用的)
Protocol 要是单独一层，一般是为了把入口出口协议从业务代码里独立出来，比如我们这里的模块可以同时支持 thrift 和 http 的同一个入口，既然同一个接口要支持两种协议，就必然需要把这种协议适配专门做一层，适配后以统一的 struct 向下传
model 其实用的也比较乱，有的项目 model 层就是一堆 struct(这种情况下，如果这些 struct 是用来和外部交互，可能又被叫 dto 了)，而有的项目则认为 model 是“领域模型”，那其实就是 logic。
logic 本身在有的框架/项目里又会叫 service、或者叫什么 business rules

名词确实比较乱，重点理解**

[nlimpid]

@cch123
@nlimpid

1. 没错，应该在 logic 里
2. 工程领域发声的人比较多，比如 martin fowler，uncle bob 和 ddd 社区里的一堆人，相似的概念他们造了很多不一样的词

Repo 和 Dao(这两个的细微差别在 IDDD 一书里有说明，但实际编码的时候大多数公司都是乱用的)
Protocol 要是单独一层，一般是为了把入口出口协议从业务代码里独立出来，比如我们这里的模块可以同时支持 thrift 和 http 的同一个入口，既然同一个接口要支持两种协议，就必然需要把这种协议适配专门做一层，适配后以统一的 struct 向下传
model 其实用的也比较乱，有的项目 model 层就是一堆 struct(这种情况下，如果这些 struct 是用来和外部交互，可能又被叫 dto 了)，而有的项目则认为 model 是“领域模型”，那其实就是 logic。
logic 本身在有的框架/项目里又会叫 service、或者叫什么 business rules

名词确实比较乱，重点理解**

理解。
我只是吐槽，我自己内部就把model干掉了，这个名词太容易误导了，我这边没有多协议的情况，所谓protocol层基本上就是protobuf文件了。我的一点感受就是protobuf生成的interface更像是一个更高层次的business rule

[8090Lambert]

工程化的东西，有时比较难推动。做PHPer开发时，受Laravel启发比较大，都是由抽象的Contract/Interface，实现具象的类。写Golang时，也秉承了这个习惯。不过很多人并不认可，首先他们觉得可读性较差（不愿意深入追代码的人占大多数），遵循起来挺麻烦，本来几十行代码的事，非要整那么多类（结构体）出来，归根结底，磨刀不误砍柴工，技术债务只会迟到，从来不会缺席。确实如你所说，首先，写单测时，mock很容易；大项目重构时，所有的具象实现类（结构体）只要按约定实现对方方法，基本无缝替换。

[caibirdme]

1. 感觉你对贵司”年久失修“的系统很有成见
2. 依赖反转得用到刀刃上，不然IDE跳不进去更痛苦
3. 你最后一个问题，我觉得遵循一个原则：谁使用抽象，就该谁定义接口

[cch123]

@caibirdme ，上班时间摸鱼，要告诉你老板哦

[caibirdme]

@cch123 摸鱼的时候看见你老板了，你说巧不巧

[cch123]

@caibirdme orz

[fxmumu]

所见略同，至少 mock 很方便。所以可以得出，不抽 interface 的基本不做单元测

[cch123]

@fxmumu ，还有 monkey patch 这种东西，不一定都得 interface 的哦