我认为......

我认为在使用Java开发Web项目时：
DAO与Action之间应该有一些个Service.
   有人喜欢把业务逻辑写于DAO中，也有人喜欢将业务逻辑写于Action中。 写于DAO中原因，我想这些人是觉得在DAO中实现方便， 而写在Action中，是那些人觉得控制事务比较合理（执行一次Action，操作完全成功，提交，要不回滚！）
   我个人觉得，无论将业务逻辑放于DAO中,还是Action中都会造成它们“肥大”而难于控制。
   放于DAO中，业务逻辑与真正的访问数据发生混淆，如果业务逻辑不复杂，将代码整理清晰还行，但我总觉得不够自然，分开可以认人直观的认识到那些是真正的与数据库打交道，那些是业务逻辑。所以我认为应该有必要增加一个业务逻辑层，利用现的DAO接口为Action服务.将业务逻辑轻松从DAO中的提取并描述出来。  
   放于Action中,也许常常由于为了某个功能实现上的方便，想当然的增加一个数据访问接口。 其实，我在做练习（或项目）也通常会这样，不过我认为这是个不好的习惯
   首先，一个清晰的架构应该在事先将接口都已定义好了，除非功能上发生了扩展或其他变化，在先前定义的接口不能满足的情况下才应该扩展底层接口。如果定义接口的人认为在不扩展的情况下仍可以利用现有的接口完成，就不应该扩展。比如，查询数据库中是否存在一个为相应名称的用户， 如果一开始就定义了获得所有用户的接口，而在实现时你更喜欢写一个SQL去查询判断结果的记录数，就想当然的增加一个判断用户姓名是否唯一的接口。

   试想,如果现在几个人协作开发，一个人架构，其他各层由专门的人负责写，也就是说写Action的人不必关心写DAO的人如何实现，他只能使用设计时底层所定义的接口来完成目前所有工作，在这种情况下，写Action人是不是该告诉写DAO的：“我觉得你应该提供给我 一个接口，这个接口的功能就是根据用户名称判断是否已经存在”，而写DAO的却说：”我已经提供给你了所有用户，你还没法判断吗？“，写Action认变写DAO的实现方便，而写DAO的却说定义的接口已经有能力完成你所要功能
   （你该获取所用户后，再进行比对），如果是你，你认为谁有理呢?(都有理，架构师的错！他干吗不事先写考虑到呢)
   如果我是写Action的，我会给架构师一个请示，如果不答应我就只能利用现有的接口去实现这个功能.因为写各层的人通常不会有大局观，不会关心修改接口的定义是否对其他人造成什么影响。对于软件更改接口不是件太难的事，如果是硬件呢，我想你不会“想当然”了吧，说在插糟那个地方打个“洞”就打个”洞“，本来有个三项插孔，并且这个三项插孔也完全可以插两个的插头，干吗还要再添加一个具有两个孔的呢，那时你还得考虑整体的美观等等的因素,做软件的“看”不到什么美不美，除了字母就是字母，看得到的就是代码是否漂亮，再就是架构是所产生的图是否清晰、优雅，没有硬件那么直观。
   其实不管是做软件还是做硬件的，道理是差不多的。总之，做事情要慎重。三思而后行！（我小提大作了!）
   所以我还是主张有个Service,将业务逻辑放在里头，即方便写测试，也将层次划分的更清晰。Action中应该是只存在控制逻辑，如果业务逻辑与控制逻辑写在一起，日子久了就难以控制了（我觉得这样做比写在DAO中更糟糕）。
   另外，说到事务处理，我个人认为放在Service更为合理，如果控制表现于DAO层那么只能对单一具体访问数据库的操作进行控制--请注意是对单一访问数据库的操作（大多时候一个Action也就对应着一个DAO操作），连续操作的控制就没招了。 如果控制表现于控制逻辑层，就只能对一次界面操作进行控制，如果一次界面操作中一个数据访问操作失败，就都失败了。控制于业务逻辑层，当然是最理想的了，因为业务逻辑才是真正程序功能的核心,是最为关键的一部分。一次界面操作或许包含多个业务操作（像工作流），而每个业务操作又或许包多个数据访问操作.控制于业务逻辑层就表现于。如果一次界面操作中一部分业务操作成功而另一部分操作失败，不会完全回滚。幸而通知用户那些操作已经进行了，那些失败及其原因。用户可以从失败的操作处进行究正，而不是从头来过，一般情况下这种情况很少，至少我像是没有遇到过.
  
 与Java相比，ROR中，有人推荐将业务逻辑写于model中，我对RoR没什么实践经验暂不发表个人观点，但从ROR测试的分类来看Java，Java的DAO测试应该是Unit Test，业务逻辑测试应该是Function Test,而控制逻辑测试应该是Integration Test,你说呢？(也是我比较欣赏ROR的一个理由吧!)

这次先说到这里，首先声明我对Java的学习与实践不多也不长，其次，我也只不过做过一个实际的Web项目，没什么经验！如果误导了你，我只能表示抱歉，可没有经济赔偿啊！如有不同意见或我有说错的、说的不好的地方请留言，我会认真改过，与那些经验老到的不能相提并论，只地发表些个人的想法，也是希望集大家的力量帮助你，我，他一起成长!

下面我会上传一个压缩文件，其中有Webwrok,Struts2和ROR的练习，还请多多指点，其中对Webwork，与Struts2练习中的服务层写的不满意，如果你有更好的见议，请与我分享，在此表示感谢！我之所以没有提供struts1的练习，是因为现在也许没多少人在去学习它，我做的第一个Web项目就是用它作的.
 如果你是真正的新手，相信会对你有所帮助，其中在看源代码时请留意Webwork或struts2中配置文件的组织，虽然还不尽理想，但我认为对你会有所启发.

评论

4 楼 riss 2007-07-12  

oh.sorry!I hasn't msn.

3 楼 mario 2007-06-18  

to_riss：
  不好意思，现在才看到你的回复。对于设计上和开发上取舍，是个度的问题。是需要具体情况具体分析的，这是个典型的废话。设计变化的可能性取决于对业务理解和认识程度。也是唯一能通过主观能控制的变化。有机会多沟通吧，我的msn： yuyang at meritit.com

2 楼 riss 2007-06-09  

mario:
说得有道理！
与平常人们怎样理解什么情况下是过度设计，有关系。
因为常常中做项目时，由于各种原因，也许不可能考虑得面面俱到;也或许，在项目完成后，需要进行长期的维护并且带有扩展（版本升级）；这就取决于一开始的设计是否更有得于扩展，重构.要求设计人员考虑问题慎重，既要考虑到现有的各种情形，还要考虑到未来可预见的情形。这样对将来的维护和升级更有利。

1 楼 mario 2007-05-30  

我觉得问题核心是在service和dao的保留上。
service的接口面向Action，是事务性质的，或者业务性的。
dao的接口面向service，是原子性的，比如add,delete,query。一个service接口有很多dao接口组成。
当业务简单的情况下，每个service和dao一一对应。似乎dao就多余了。
当业务复杂的情况下，每个service和dao一对多，似乎dao就不多余了。
尤其是spring的HibernateTemple成了通用版的dao或者别的基于泛型的dao，dao似乎变成了鸡肋。
必须有的所以我认为在service情况下，dao是可选的。 是需要根据实际情况演化出来的。