大家有什么好的建议？

Question

近来在使用s2sh开发项目时和一位同仁就后台业务逻辑开发出现了分歧，他主张在struts2的action中传递sql语句到后面，后台处理前台传递过来的sql，完成相应的操作。而我则主张通过用例驱动，确定服务层的接口，struts的action只调用服务层的接口，不用写sql。我那位同仁认为我这样编写代码会导致服务层的接口太多，他那样设计只需在action中编写sql,后台服务层无需改动。但我觉得这样表现层与服务层耦合度太高了。
大家有什么看法？还请赐教！

Answer 1

都差不多的。
1,你同事action层代码肯定很多。
2,你service层代码肯定很多。我认为其实两种方案都可以。

Answer 2

谢谢你的建议，不过事务一般设在服务层，有时action中同时要调用服务层两个方法，我担心这样可能会造成事务的不一致啊！

Answer 3

action中还是不要写太多的东西，只负责跳转什么的就可以了。
而且还要看你们的事物处理控制在哪一层上..

Answer 4

action里不应该写sql，违背了分层原则

Answer 5

这个肯怕是一个仁者见仁，智者见智的问题。我只是想建议
(1)采用最好的技术未必是最佳解决方案，而是最适合客户需求的技术才是
(2)基于上述理由，拘泥于MVC分层之类，那是过于教条；
(3)如果LZ的同事是基于系统后期的维护的方便和灵活性，那是一个不错的理由，我认为LZ应该认真考虑。

Answer 6

My advice is :
solve by fist.
武力解决.sevice还是分开比较好.可以重用一部分service.
也不差那点代码

Answer 7

正规开发业务逻辑一般不写在 action中 这样便于管理耦合度低   支持楼主观点  

Answer 8

标准的web开发基本都是action--->services---->dao 这样的模式，action中指负责跳转一些非常简单的操作，组装sql可以在services层进行，再传递给dao做数据库操作。毕竟services层是业务逻辑的核心代码层，涉及到业务逻辑的操作应尽量放在这里，dao让他只负责执行sql语句和传递结果这样的操作。