三层结构一些想法
这个是很正常的用SSH或SSI的三层架构啊
action--service--dao
实际的项目毕竟不是玩具都算不上的helloworld
DAO层里面一般只是实现单一行为的sql
而service则可能需要调用多个DAO里面的多个方法才能实现一个业务逻辑
action层负责调用service里面的业务方法，把后台返回的数据包装成前端用的数据，还有一些数据校验
在实际系统里这个是一个很合理的架构模式
==========================================================
呵呵，事实上我开发这么久的 经验就是最初的所谓高扩展性设计最后往往 都没有用 。还非常累赘。
天下武功 无坚不摧 唯快不破。将项目合理的分析（细）、模块和结构清晰；最大限度的提高开发效率，“让大象跳舞”，提高应对变化的速度。才是最接近银弹的解决方案。
而这，是编码以外的事情。
====================
首先我再次声明，目前在这么庞大的设计架构背后，只是一个小小的管理系统， 用的是SSI+EXT
JSP里应该避免写任务的JS， 那我JSP里写什么呢， 用了EXT， JSP里一般HTML都不用写。
Action存在的意义其实是动作，可以理解成Model，而非控制（Controllor），可以去看struts2文档，它就是让你写业务
service层其实可以写成抽象Action，写一些公共的业务逻辑，实体Action继承这个抽象的Action，不是更好吗
DAO层其实已经在ibatis里实现，ibatis就是项目中的DAO层，它的每一个操作，都是实现对数据库直接操作的一层，你的SQL都写在XML里， 这跟我们以前用JDBC手动写的一层DAO有何区别呢
=============
1，使用OPOA，只有一个jsp，一个页面一个js。
2，如果用ext，不要用struts，用springmvc直接responsebody
3，其他同以上我说的
=============================
有时候有弄明白自己到底想要什么？
为什么要这么写？
不要为了action而action，为了service而service
J2EE很多时候告诉企业开发，要这样做、可以这样做。
而很多人没去考虑 为什么这样做，这样做对自己有什么好处。
