层的职责的请教

大家回答得挺好，从各个方面说明业务层Service必要性。

我想从DDD（Domain-Driven Design）观点来补充说明楼主这个层次得必要性。

按照DDD领域建模观点看，中间业务层还应该再分为应用层和领域层（具体文章见http://domaindrivendesign.org）。
楼主的Service属于应用层，Domain则属于领域层。

在DDD观点看来，领域模型Domain其实分为三种元素：实体Enity、值对象（Value Object）和服务（Service）。

模型对象分实体和值对象，其实就是实体对象和对象状态的区分，值对象表示对象状态，在我设计JiveJdon3中，有ForumState和ForumThreadState，其实它们就是值对象，对象状态非常重要，它和对象生命周期scope有密切关系，最近出了一个Scopes开源免费框架就是专门提供对象生命周期管理的，所以，作为一个业务层框架必须有提供生命周期管理功能。
状态对象：数据库的替代者

服务是一些行为功能，有人指出没有行为的模型只有getter/setter
,是不是贫血模型，或者叫失血模型，DDD专家Eric Evans认为：将领域需要的功能强加给实体和值对象，不仅会破坏模型中对象定义，而且会认为地添加毫无意义的对象，

失血模型的请教

现代业务平台架构应该在什么理论指导下？无疑是MDD模型驱动设计和DDD，Eric的DDD是一本具有很大影响力的书籍
领域建模是一种艺术的技术，不是数学的技术，它是用来解决复杂软件快速应付变化的解决之道。
http://www.jdon.com/mda/ddd.html

没有必要。
如果为了变化，新的需求过来之后，从前台到你的controller，service也是都要改变，你适应变化的能力不一定能增强。
层和层之间的连接有时就像蜘蛛网一样，你增加过多的层次只能让你的头更疼。
.net,ror都是很不错的框架

唉。。什么SERVICE层。。这些都是拿来做两个例子感觉一下还可以。。根本无用。我就搞不懂了。。。为什么不能直接从controller中调用DAO??
还要来个SERVICE...controller中不能拿写业务逻辑代码？？

无非就是把一些代码提出来而已罢了。。非要说的好像很高深似的。。。。
你的业务逻辑变换了。。SERVICE不变？？怎么扩展？？看着那个APPFUSE就恼火。那个东西如果拿来做项目。。。。我无语。典型的理论东西。一大堆的无用接口。特别似SERVICE接口。还是应该把精力多放在系统框架的塔建、接口和类的设计上面。这些层不层的东西有什么好讨论的。在设计中需要时层自然就出来了。没有必要什么东西都按模子来。

> 唉。。什么SERVICE层。。这些都是拿来做两个例子感觉一下?> 可以。。根本无用。我就搞不懂了。。。为什么不能直接从co
> troller中调用DAO??

看你这么说，那我问问你，你写的系统中，事务逻辑以及各种非数据库相关的业务逻辑放哪？放controler？那好，那如果两个业务需求，同样的一些DAO数据库操作，由于业务需求的些许不同，控制事务的逻辑不同。那你是不是写两个controler？你是不是把这些逻辑不同分别重新各写一遍进去？你是不是觉得两个controler的代码很类似，用复制粘贴就可以复用了？那如果除了事务其他的一些非数据库逻辑也参合其中呢？情况是怎么样？复制粘贴反正都可以搞定是吧。我打赌你的代码里面一堆重复代码，上千行都难说，呵呵

很多东西虽然拿出来讨论大家都明白，所以让人就觉得不就那么回事吗？呵呵，其实不然，没有理论作为基础，就是再牛，说的不好听，都是小打小闹，只不过我学习理论的同时需要充分理解它，而不是被它束缚了我们的思维

你这么想也不为过,看项目大小而言吧,过小的项目强调过多的规则只会人为的增加其复杂度.
不过项目大了以后应该详细分层,否则是给自己找麻烦.有句话说得很好"一个编写得好的程序员是自己的天堂,一个编写得糟糕的程序员是自己的地狱".

banq大哥,请问Service类中的各个方法是静态的好还是非静态用命令模式调用好????

ffffff

谢谢大家,我的迷团都解开了.收获很多!

service这一层的用途和用法迷惑了很久了，今日才得解开，感谢各位！
另外加一点本人的认识：
分层的基本出发点是技术环节解耦。

关于持久层的解耦，yang1981说得太清楚了，下面引用：“数据持久层是服务层引申出来的。服务层完成业务操作，需要持久化数据或取回已持久化的数据，所以会抛出持久化（数据访问）需求。数据持久层的职责就是满足服务层抛出的持久化（数据访问）需求。所以对于业务层来说，不关心持久策略是什么，只关心有没有满足它的持久需求。按照这样的思路来保证持久策略的可变性。”

另外谈一下本人对表现层解耦的认识：多年来软件变化最大、最快、最激烈的其实是表现层，从字符界面、图形桌面、Web，到现在的Ajax、RIA。过去以foxbase和VB、PB、Delphi为代表的应用系统，表现层和业务层是完全耦合的，当表现层变化之后，立即面临被淘汰的命运，这是惨痛的教训，绝不应重演。B/S大潮后的这几年，很多人把Web作为表现层的终点，所以RoR才会炒起来。但历史经验表明，Web绝不可能是终点。当下一个革命性的表现层成熟的时候，Web仍会退位。
真正可怜的是业务层，其实变化很小，而扩展无限。每次随表现层的变化推倒重来，既是程序员的恶梦，更是企业的恶梦。我们一定要将二者分开，不要再成天重写系统了。保护、扩展企业的业务逻辑，当是每一位程序员的天职。

持久层(Dao：接口，定义了持久化方法，CRUD DaoImpl：Dao的实现)
数据层(Domain：提供getter/setter)
控制层(Service：业务逻辑)
getUserOrderByID() getAllUserOrder() 两方法是持久化的需要如果不能跟持久化扯上什么关系最好也把他定义到数据层,而后面的<根据地区查询客户getUserByArea()，或者根据产品线和地区查询客户 getUserByAreaSrv()>这应放到数据层中，他关注的问题只是数据，而要实现他的业务逻辑还需其他的业务类来调用

==================================
这个有点不明白，在Domain对象里应该有持久化的操作吗？像getUserByArea方法应该是会涉及到底层数据库，难道在Domain对象里也需要如SQL之类的东东吗？
我的理解Domain对象里的方法应该都是只对本身操作，getUserByArea之类的方法很可能会返回一个集合，感觉不是很合适
[该贴被deathmaster于2007年05月18日 10:51修改过]

我的做法是放在dao里面，个人感觉比较清晰。

我常用的一个分层思路，有4层，分别是：视图层、控制层、业务层、数据访问层
你所说的DAO,就是数据访问层，其实他的职责就是执行sql操作
视图层：jsp等
控制层：servlet，struts框架的控制层ActionServlet也是一个servlet，
他的职责就是转发视图层提交的数据，以及根据业务层的返回结果，确定
下一个视图
业务层：javabean负责，处理系统的业务，一般就是封装一条sql语句出来，
然后传递给数据访问层，进行sql操作
数据访问层：就是执行sql操作