happy path！好像是有一些业务走在自己的路上，没有明确的遵守框架该有的规范。
当一些业务没有被正确的设计， 明确下来就让人去写代码时，会出现上述错误。
我可能把javascript看的过于强大了。
老实说我java入门花了好久，后来框架搭起来发现写银行系统的程序相当无聊，就是业务上的增删改查。学了javascript后，觉得javascript代码写的爽快，可能动态语言，而且程序短小的关系吧。
从我的从业经验来看，感觉自己的分层体系结构代码就是CRUD的原因有如下两三种（这里只针对一般的ssh框架或者js+服务端框架）：
1、大量的Business logic被写到了表现层（如struts的controller或者是js代码中）。
2、由于未能正确识别服务边界，导致大量真正的商业逻辑散落在表现层、服务层、util类、dao、甚至sql代码、存储过程等。而中间层，则是一个service一个dao等出现。
3、缺乏必要的逻辑，很可能导致系统处于业务在happy path的路上裸奔。
有几个建议如下：
1、js是为了用户体验而实现的，一切都是为了用户体验，除了展示功能，做任何验证也都只是为了体验上的提升，而并不能把真正的业务逻辑验证放在js端，这是非常危险的事情。
2、controller的一切都是为了协助前端视图层展示服务，包括验证，不能将逻辑依赖他。
3、服务层才是真正的业务逻辑宿主，所有的业务逻辑都应经过他验证、认可，同时他也是最后一道保证数据一致性的门卫。
4、一个服务只有简单的crud没有其他任何业务的情况下，并不适合作为一个公共的服务暴露出来，除了其维护自身的页面，他应该是某个服务的附属品。
5、用aop的时候要注意，切忌不停的切片，切多了让逻辑过于分散，会导致失去维护焦点，而其所谓的扩展性往往大部分时候都没什么用。
无论是从安全、业务的完整性上来说，
happy path！好像是有一些业务走在自己的路上，没有明确的遵守框架该有的规范。
当一些业务没有被正确的设计， 明确下来就让人去写代码时，会出现上述错误。
我可能把javascript看的过于强大了。
@淡淡泛街:happy path！好像是有一些业务走在自己的路上，没有明确的遵守框架该有的规范。 当一些业务没有...
前端也是很好玩的。对于一个有志于从事软件研发的程序员而言，擅长1～2个方向也是正常的，只是，不把路走窄了，明确知道自己掌握某个知识的目的是什么，也是好的。大部分时候我们学某个知识只是为了充实整个知识体系，是之一而不是唯一。你懂的
。
3、服务层才是真正的业务逻辑宿主，所有的业务逻辑都应经过他验证、认可，同时他也是最后一道保证数据一致性的门卫。
什么叫所有的业务逻辑都应经过他验证,认可??? 在我接触过的项目中,service干着和Dao差不多一样的工作. 只不过service层只是Dao的前台表演者,真正对数据库起作用的还是DAO本身.
我在项目上,很少把一些校验性的代码放在Service层.
@周浩杰:3、服务层才是真正的业务逻辑宿主，所有的业务逻辑都应经过他验证、认可，同时他也是最后一道保证数据一致...
考虑一下如果服务仅仅退化为一个dao和controller的传递者，看看现实中发生的：
1、缺乏验证：也许大部分时候服务只是你自己在用，你自己传入预定的参数（happy的参数），你自己负责处理这些参数。但当其他程序员维护“这个服务”的客户代码，他人需要调用你的服务，传入了“不友好的”参数，无论恶意还是无意的，因为你没有经过验证，你也没有测试一些边界条件，你的系统充满炸弹。
2、大量的重用逻辑散落在不同的代码中
3、你在服务中除了能集中调用dao的代码，你集中不起来干其他事，比如业务缓存对外的透明处理、区分服务边界等。
