补充一点，使用model.dao()也是无法做到使用非查询方法进行报警的效果，在实际开发中，会对Model进行很多扩展。还有就是，如果能分开，就可以对DAO和Model分别进行业务上的扩展，比如findByName()这样的方法我就可以只扩展在DAO上。

以上就是我对这个问题所有的思考。

刚才试了下,确实在dao可以做数据保存的动作,如果不仔细看文档,就使用jfinal的初级选手来说的话,确实会用这个dao来进行数据保存的动作

如果 dao 对象是来自于 dao() 方法，是无法进行 set，更没法进行保存、更新这类操作的，new 出来的确实是可以的

最佳实践，这个 dao 并不建议放在具体的 model 之中，而是放在 Service 层中，这样做就是分开的，model 只做 model 该做的事情

有得必有失

我只是觉得Model上不应该有查询方法，Dao上应该只有查询方法，通过抛异常来阻止，只能是在运行时进行，而且也阻止不了使用new Model().find()。

新手们容易混淆，使用不当，给程序带来隐患。拆分开也是很有利的：

1. 概念清晰，更好理解
2. 降低耦合度，更利于维护，方便日后扩展
3. 可以在IDE中放心使用方法提示，不用担心出错

demo例子偷了个小懒...大家就跟着"懒"23333

这是一个可以思考的方向，下面是一点随想，大家可以开放式来探讨：

1：model 实现了 ActiveRecord 设计模式，这个模式决定了 dao 与 model 是合二为一的

2：dao 对象一定要创建在 service 层中，所有查询全部交给业务层的方法来做

3：如果将 dao 与 model 分开，有什么好的设计方式，如果真的有好的设计，那么需要再添加一个 dao 层，为每个 model 添加一个 dao 类文件，这种模式开发者是否接受，值得探讨

欢迎大家一直留言跟进

我觉得没有必要，想laravel php框架model也是dao放在一起的，使用起来也比较方便，拆开感觉代码很冗余，我个人比较喜欢model和dao结合在一起。

楼主说的并非没有道理，确实对于新手如果不了解的话会比较容易犯错。现在的model是实体和dao的结合(貌似这叫充血模型???)，它需要new一个单独的model对易用来当dao,其它就当是数据库记录了。了解清楚的情况下，还是挺好使的。建议新手花一点时间来了解一波再下刀，这样用起来会比较顺手。我之前很喜欢用Db,一直不关注过model，后面硬花了点时间来了解一下，发现model在某些情况用起来会比较方便。model和Db结合使用才是最合理的