@淡淡泛街:happy path!好像是有一些业务走在自己的路上,没有明确的遵守框架该有的规范。 当一些业务没有...
前端也是很好玩的。对于一个有志于从事软件研发的程序员而言,擅长1~2个方向也是正常的,只是,不把路走窄了,明确知道自己掌握某个知识的目的是什么,也是好的。大部分时候我们学某个知识只是为了充实整个知识体系,是之一而不是唯一。你懂的。
老实说我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!好像是有一些业务走在自己的路上,没有明确的遵守框架该有的规范。 当一些业务没有...
前端也是很好玩的。对于一个有志于从事软件研发的程序员而言,擅长1~2个方向也是正常的,只是,不把路走窄了,明确知道自己掌握某个知识的目的是什么,也是好的。大部分时候我们学某个知识只是为了充实整个知识体系,是之一而不是唯一。你懂的。
@周浩杰:3、服务层才是真正的业务逻辑宿主,所有的业务逻辑都应经过他验证、认可,同时他也是最后一道保证数据一致...
考虑一下如果服务仅仅退化为一个dao和controller的传递者,看看现实中发生的:
1、缺乏验证:也许大部分时候服务只是你自己在用,你自己传入预定的参数(happy的参数),你自己负责处理这些参数。但当其他程序员维护“这个服务”的客户代码,他人需要调用你的服务,传入了“不友好的”参数,无论恶意还是无意的,因为你没有经过验证,你也没有测试一些边界条件,你的系统充满炸弹。
2、大量的重用逻辑散落在不同的代码中
3、你在服务中除了能集中调用dao的代码,你集中不起来干其他事,比如业务缓存对外的透明处理、区分服务边界等。