@no1xsyzy 你说的错误案例，这个关系怎么理解呢？另外，感觉你说的错误案例和我的第一个 case 挺像的啊，“把 SQLite 当 kv store，才能这么玩” ，如果没有当成这样，那应该是怎么样玩？我觉得这样玩也没什么问题啊...

还望能提点一二

@no1xsyzy 正确案例 404 了，不知道是不是仓库没开公共权限的原因，看不到(哭

@bsg1992 如果说两种都不合适的话，想请教一下，你们项目里面是怎么处理数据获取的逻辑的呢？方便的话希望能提供个简单的 demo，感谢~

@no1xsyzy orm 是可以做到 User(id=12).addName("john") ，然而不想在 service 层直接调用(虽然也可以)User(id=12).addName("john") ，所以才将 它变成了 user_model.addName(),这样 service 层都不需要关心他是关系型数据库还是 nosql 添加的，还可在函数里面做一些额外的操作。这是我抽离数据获取逻辑到一个函数的原因。

然后才是我真正的问题，既然我选择了抽离，第一种和第二种哪种合适？如果都不合适，那想请教一下，你们项目里面是怎么处理数据获取的逻辑的呢？方便的话希望能提供个简单的 demo，感谢~

@bsg1992
"按照目前的做法 ，无非就是在 DAO 层 增加一个与之对应的接口。"
第一种写法不就是在做这样的事情吗？ orm 是获取数据的，将获取数据的逻辑抽出来放在 dao 层，至于这个获取数据的逻辑函数，里面是通过 orm 获取，还是通过原始 sql 获取，都是可以的。

并不是说要做 orm 的封装，而是要把数据获取的逻辑抽离到 dao 层，然后才是我真正的问题，选择了这样抽离逻辑，第一种和第二种写法哪种更合适一点？

”dbContext.XXXTable.where(x=>x.age>=18 && x.sex =1).group(x=>x.school).sum(x=>x. score)
这样的查询你如何封装呢？”
按我的理解，就按照查询意图去封装，这个例子就是想获取 sum，那就在所谓的 dao 层弄个 getxxxSum(age, score)这样的方法

@no1xsyzy 感觉有点误解了。这个 xxx 代表的是 user_model 之类的数据访问层的意思，方法的目的是为用户增加昵称，那放在 user_model 里面这个问题不大。
数据访问分层没有强调降低复杂性，而是强调分层，职责分离

@ChoateYao 你这例子我感觉跟第一种都是一样的，dao 本来就是一个分层收口的作用，强调一个分层，你现在 dao 类也是基于 orm 封装了一层给外面用，我只是少了 dao 这个类，直接用了 orm 而已。例如你的 delete(id)函数我就变成了：

function delete(id) {
user = UserORM.find({id = id})
if (!user) {
return error
}
user.delete()
}

@ChoateYao 那删除是直接在 service 层调用？但是我想问的问题不是这个，而是哪种封装更合适一点？
我觉得，像第一种的那样，我明确告诉你就是用了添加用户姓名的，不满足你的直接再封装一个，这样的界限明确。
第二种这样，半通用半不通用的风格就比较难受，你说我要扩展的时候，是直接改你的，还是直接封装个新的？而且 新增__insert 这样的映射，有了 orm 还搞一套命令映射，我有点不理解....

@no1xsyzy 没太 get 到这个点

@VeeSong 明白，这是我期待的答案

@bsg1992 那想请教下，你认为 orm 和 dao 共存的时候，具体的使用场景是怎么样的？什么时候直接用 orm 进行链式调用，什么时候用 dao 呢？可不可以举个例子区分一下呢？十分感谢！

@bsg1992 最后一点我可能不太认同，不想 orm 在 service 层满屏飞，还是在 dao 封装一层好一点，即使是简单的调用

@konakona 这又涉及到了 eloquent 和 Repository 的 区别了...
你在 model 里面定义了一些数据操作的函数，在 DTO 里面只有数据传输对象，我是这么理解的...

eloquent = 数据表映射 + 数据操作
如果你用了 Repository pattern，那数据操作应该放在 Repository，eloquent 仅仅是一些数据表映射，属性定义就好了

@dayudayupao 所以 dao 层可以用 orm 去搞对吧？写的函数就类似于我 7 楼写的那样？

@konakona 看了一下，你的 model 层除了定义了实体类型以外，还在此层基于 orm 封装了一些数据存取函数，这样看你的 model 像是 DAO + model，那你的 DTO 的职责只是定义了数据传输的对象结构，不知道我这样理解有没有错

@konakona 问题是不知道 dao 里面写的什么代码？！

@catcn 组合体怎么理解？

@konakona 所以是有了 orm 之后其实不需要 dao 层了？

@pkoukk 在写，就是觉得 ORM 用着挺方便的，加一层 DAO 是有好处，但是看着好像不太大的样子