网页前端设计

http://www.86y.org
feedskyQQ邮箱

搜索文章

对asp.net开发中分层的理解

关注我吧
 2012/8/31 10:38:04 阅读次数:2348

我也来讲讲我对asp.net(C#)开发中的分层的理解吧.

从一开始接触asp.net到现在算来也有几个年头了,从学校中老师就有教过基础了,不过都是范范!压根不知道分层的概念,后来值到去年在公司有时候向他们学习C#.net,然后他们问他们三层结构怎么做,就这样一步一步,我渐渐地学会了用c#.net。(幸凡学习网就是一个很好的实例)!

刚学会我就把我的个人网改成.net版的了,当时我觉得分层也没有什么效果啊,但因为当时没有做过什么项目,看到别人对分层的讨论总是知之然而不知其所以然。后来自己尝试用分层做了一个企业网站的项目,由于项目并不大,并且所有的前后 台代码均为本人独自完成,老实说,并没有感觉到分层的好处。

最近几年的.net项目开发中,大部分也都是一个人在负责分层开发中的多种角色(数据库访问、业务编辑处理、前台表现及JS、JQUERY、 AJAX等),另外由于大部分都是一些不太复杂企业网站项目,所以一直没有分层。比如开始一个新的项目,如果其他项目已经实现了该功能,则直接把文件 copy过来,表名一改就可以用了。对于有类似功能但不完全对应上的,拿过来稍加修改也OK了。除非一点复用可能也没有的功能模块,才可能去开发。这样经 过几年积累,我可以毫不夸张的说,一般的企业网站,利用手头的代码,有个一两个小时绝对能够搞定,从这点来说,我个人并没有觉得分层有什么太多的好处,因 为如果一开始就采用分层开发,一方面分层开发本来在层之间传递数据的效果相对直接在aspx.cs中访问数据库而言,我认为肯定是慢的。另一方面,如果涉 及到小的字段修改,如果采用分层开发,那么我就要把涉及到的每个层都修改一遍,而实际对于小项目而言,如果不分层的话,往往某个字段只需修改两处即可。 (前台一次,后台一次)

那么,分层究竟有没有好处呢,网上对分层的讨论始终也没有停止过,优势劣势各有,大家各执一词。从我个人而言,虽然实际应用中分层的时候并不多,但 我并不否定分层。最近要开始一个大项目,也在网上查到了好多关于分层的资料。对于分层的好处,我觉得主要体现在以下几个方面:利于团队开发、团中的各个成 员职责分工明确,各司其职即可,另外有利于系统以后的扩展,如BS转CS,SQLSERVER转ORICAL等,至于后期的容易维护,目前还没有太深的体 会。

综上所述,我认为小项目没有必要分层,小项目的分层说俗一点,完全是脱了裤子放屁,找费事。小项目做完了就是做完了,做为客户来说,懂网站的都不 多,更有谁会去想把一个小项目改来改去的,今天BS,明天非要弄个桌面程序试试呢。对于大项目而言,我觉得还是有必要分层的,即便开发人员不多,甚至一个 人去做的话,也还是有必要分层的。分层之后,可以把思路集中在考虑某个层上。不过话又说回来,大项目的分层,我想每个公司之间或者每个人之间的分层定位也 不会分的那么特别清楚。

从CSDN上看到一篇贴子,其中有对于分层的举例说明,个人觉得还是非常浅显易懂的,一并贴上。

三层的理解
  1、UI层:我说的这个UI层可能包含了很多的概念,除了大家都知道的window form和web form,它还包含了那些可能没有用户界面的用户接口,像window service,web service以及.Net remoting service等的入口,它们都可以看作UI层,而UI层应该只和业务逻辑层发生关系。有些系统尽管划分了层次,但却将部分的业务逻辑放在UI层,这就增 加了UI层和业务逻辑层的耦合度,不利于UI层的增加或变换,因为如果需要再增加另外的一个UI层,而新增加的层中又包含了原有UI层的部分功能,这时新 的UI层不得不再一次实现同样的功能,如果已实现的功能不符合要求,需要修改时,又不得不在已实现了的多个UI层中进行改动,这样不但增加了工作量,而且 增加了出错的可能性。 
  2、业务逻辑层:所有的业务逻辑处理的集中地,它为UI层提供服务。比如一个购物系统,当客户下了订单时,一般应该做这些事情:1、检查提交的数据的合法 性;2、验证客户信息;3、检查商品信息,比如商品是否存在,是否有足够的库存等;4、提交订单。这四步对于UI层来讲是透明的,就是说UI层只调用业务 逻辑层的一个相应的方法,而不是亲自完成这四步功能,因为这四个步骤实现了一个完整的业务逻辑,它们不可以分开。如果需要公开一个Web Service,供客户提交订单,Web Service的实现也只是简单的调用业务逻辑层的一个相应的方法。 
  3、数据(库)层:这一层才真正的实现了数据的存取,它为业务逻辑层提供服务。在这一层上不需要关注业务逻辑,只是存取数据。对于确定只用一种数据存储方 式来讲,这些就足够了。但在一个分布式的系统中,这种简单的实现是不够的,因供存取数据的不一定来自数据库,也可能来自其他数据文件,比如XML、 Excel等,不同的数据库之间也有很大的差异,这些异构的数据对业务逻辑层来讲都是透明的,业务逻辑层没必要了解数据存取的细节。那么如何才能实现这种 结构?通常的办法是为数据(库)层提供一个接口,业务逻辑层只是调用接口所约定的方法,这样通过接口就可以实现很多异构数据的存取了。

三层的好处很多  
  比如具有灵活性,可以随意调整组件的位置和服务器的位置,可以增加和修改各个组件,更主要的是具有了商业逻辑的灵活性,因为中间层的商业逻辑层负责商业逻辑。  
  比如说容易更新,不用重新编译整个工程就可以更新功能,替换一个组件不会扩大影响到整个工程。  
  比如说容易维护,各层意义明确,不会出现商业逻辑和各种访问控制混合在一起的情况,而且分层的好处是,各层可以使用不同的配置,各个服务器的维护也变得简单。  
  比如说有天生的网络化,只要配置好一个外部环境,各个组件运行时不会注意到自己访问的是网络资源还是本地资源,这种分布式的好处对于一个企业来说是急需的。  

 

分层,无非就是松耦合,便于维护,也便于理解

没错,你们一个人做一个模块,但是如果再给你一个模块,那么连接数据库的那些代码你是不是又要重写一遍?
或者说,你要再拷贝过来一份,如果出了Bug,你是不是10个模块都要去修改?

对数据库的访问可以单独做成一个项目,然后引用到你做的所有模块中去
这个是我认为的分出数据层的意义

结语:

分层,无非就是松耦合,便于维护,也便于理解


大家有什么问题或技术上的想法可以在此与大家分享,也可以加入前端爱好者QQ群(141999928)一起学习进步:【幸凡前端技术交流群】

如果您觉得本文的内容对您的学习有所帮助,捐赠与共勉,支付宝(左)或微信(右)

0
无觅相关文章插件,快速提升流量
阅读全文内容关闭