关于分层和职责
2008-04-11 10:17
253 查看
现在,人人都会用MVC的模式,都知道分3个层次来处理系统。分了3个层次,而代码的分界确又是堆砌的,爱堆哪就堆哪,这样和没分层又有什么区别呢?表现上看起来好点罢了。
我看到很多的代码,在aspx.cs页面处理了很多的业务逻辑。在简单的网站,也许你认为没有业务逻辑,所以都可以写在aspx.cs。事实上并非如此。页面的显示视图不一样,也是逻辑。对于输出View的控制所有东西都是逻辑。在业务逻辑层上,很多人喜欢重复调用下数据层的东西,那种重复劳动太值了,多了一层多处理,又没有起到应有的作用。在业务逻辑层还出现GetXXXByUserID之类,就说明你出现了吃力不讨好的事情了。
分层的心态是好的,可没做到份上。事实上,原则应该如下:
表现层,用以处理所有用户输入和数据显示问题;
业务逻辑层,存放所有“业务逻辑”,所有处理,算法等应该放的地方;
数据访问或资源层,存放用于检索、修改或存储数据的所有代码。
简单的说表现层只处理输入和数据显示,当然还包括JS之类的处理。其他一律可以放到逻辑层处理。而数据访问层,说简单就是增删改查四个动作,其他的一律提到逻辑层处理。这样逻辑层的东西就可以具体的根据相同职责来分分合合。这样代码就清晰多了。
哎~,可这个世界就有如字不可教的大量人存在。
我看到很多的代码,在aspx.cs页面处理了很多的业务逻辑。在简单的网站,也许你认为没有业务逻辑,所以都可以写在aspx.cs。事实上并非如此。页面的显示视图不一样,也是逻辑。对于输出View的控制所有东西都是逻辑。在业务逻辑层上,很多人喜欢重复调用下数据层的东西,那种重复劳动太值了,多了一层多处理,又没有起到应有的作用。在业务逻辑层还出现GetXXXByUserID之类,就说明你出现了吃力不讨好的事情了。
分层的心态是好的,可没做到份上。事实上,原则应该如下:
表现层,用以处理所有用户输入和数据显示问题;
业务逻辑层,存放所有“业务逻辑”,所有处理,算法等应该放的地方;
数据访问或资源层,存放用于检索、修改或存储数据的所有代码。
简单的说表现层只处理输入和数据显示,当然还包括JS之类的处理。其他一律可以放到逻辑层处理。而数据访问层,说简单就是增删改查四个动作,其他的一律提到逻辑层处理。这样逻辑层的东西就可以具体的根据相同职责来分分合合。这样代码就清晰多了。
哎~,可这个世界就有如字不可教的大量人存在。
相关文章推荐
- 关于分层窗口文字输出透明的处理方法
- 关于颜色、纹理和分层的目标检测(object detect)相关论文
- 关于Service Identification,SOA服务划分和定义--1. 服务的分层
- 机房收费重构——关于面向对象和分层的纠结
- 关于WPF的分层窗口
- 关于CTO职责的理解
- 关于前后端分层测试的思考
- 关于数据库设计中的分级分层问题的总结(适用于组织结构图及家谱等问题)转
- 关于互联网之技术总监工作的职责职能比较好的文章收集
- 关于SFTP和网络分层的理解
- 分层中的~条件过滤~每个层对于“条件过滤”的职责
- 关于主管及其职责的常识
- 关于分层结构的感悟(轉)
- 关于软件设计分层的一些思考
- 关于CTO职责的理解
- 关于颜色、纹理和分层的目标检测(object detect)相关论文
- 关于DTO分层作用
- OA中总结:s:select,关于使用modelDriven,项目分层,@Transactional,jspf,各个层上配置注解交给spring管理的方法,简单的OGNL表达式写法
- 关于分层遍历二叉树
- 关于数据仓库的分层