我的理解service可以是一个可以复用的业务逻辑和方法,看你的情况需要

jfinal 直接定义一个类的成员变量的service就可以了吗？

--- 这句话想表达什么意思?

service 层只是抽取出了一层，不然把所有的业务逻辑写在controller里，将代码全部平面展开，既杂乱又不分层，这又不面向对象，也不利于开发和维护。按照另外的说法，对于后期分布式的展开也是灾难。ssh以前的项目，抽取一个service层道理应该也是如此。再抽取多一个dao层也是为了应付数据库连接的变更（虽然几乎很少遇到需要变更数据表的）。根据项目来拆分层次吧。可能 service 层，dao 层，如果项目需要，进行适当的增加层次我觉得也是可行的。

@kyytyp 看到挺多的用jfinal做的开源项目 直接在model中写逻辑，感觉也还行。你们平时都有这一层吗，controller怎么注入service的？直接static new 吗?

@linuxea 就是 demo 中的那种 static BlogService service = new BlogService(); 不知道大型项目中用到jfinal是怎么处理的。

jfinal 直接定义一个类的成员变量的service就可以了吗？

-- 讲讲这个

spring 的注入本质上也是一个分层。计算机世界里遇到一个问题，通常很多都是加入一个新的层次来解决。缓存的概念也是如此。jfinal 没有注入的概念，只有 new。为了保持 service实现类的 单例性。可以通过定义一个 static service 变量来完成，达到同样的单例目的。

@linuxea 其实倒也是可以写个简单的工厂类工具。如果业务写在model中 会有什么很大的危害吗

@Lg 如果要写工厂模式的话，那你可以写一个考虑所有 service 的工厂，不然还是用static 变量的形式，否则也只是多添加一个类而已。
业务写在 Model 里不是不行。我刚用 jfinal 的时候就没有把业务写在 model 里，一来是 bean 定义会被破坏，二来是 now Model的时候会产生额外的负担。所以我不建议这样做。你把业务逻辑写在 service 里面吧。这样好点。（个人建议

@Lg 写个总的 service factory吧. 感觉不错

不是有没有必要， 而是必须要引入，以前老版本的 demo 仅仅是演示，没入 service 进去误导了不少人，新版本的 demo 加入了 service

@linuxea 好的谢谢！

@JFinal 嗯嗯 知道了。

所以把service层省了，直接在controller里使用dao查数据库，除了代码量少了，有什么危害吗？？？

@MissThee 没危害 仅限于 pojo的查询,service层有利于方法的复用,使代码层次分明