突写,再谈面向对象

近几年,有开发的人员多了少,但在编码思路上却没看什么新的变化或长进,基本上都是好几年前的套路。现在基本上都用上面向对象的思想进行开发,但我从代码的字里行间里面看不到面向对象的编码思路,基本上从数据读取数据后,简单把行记录转化成结构化对象,业务代码基本上都堆积在控制层及视图层中了。或者很多开发人员在写业务对象的时候觉得没有什么东西可写(潜意识上认为在业务层中就是把行记录转换成对象,然后丢给下层去处理就可以了),至于这么写会有什么问题,问题会有很多,但比较重要的问题就是对数据库过于依赖,最终于做出来的架构看上去象是面向对象的,实则是面象过程的开发,久而久之开发流程会慢慢近象于瀑布开发流程(最终无法迭代开发,进入一个开发死角),同时用户的需求也很难实现,这样产品的存活周期也就不多了。

 

其实现在很多开发人员用的是面向对象的工具,但由于一些客观原因开发的是面向过程的代码。当然,现在这个时代不可能存在100%的纯面向对象的开发(但存在100%纯面向过程的开发), 为什么这样说,有几方面的因素:

1.       二维的关系数据库,很容易产生过程化编码思路。很多项目的开发初期,都是先从数据层开始设计,也就会导致依赖于它的业务层也会变成过程化的简单结构对象.

2.       前端的视图的表现形式也是过程化,因为视图的表现形式依然为二维为主,这样导致提供给数据的控制层也会理所当然当然过程化。(控制层是视图层的数据提供服务方面,控制层是无法做成面向对象的,这个是没方法的)

3.       对MVC的错误理解,这一点我深有体会,现在的开发不管何种语言何种项目,上来就是一个MVC,您可以查一下,最初的MVC的作用充当视图层与控制层,现在开始业务层也有它的份(我们需要区分一下视图对象模型和业务对象模型的概念,您会发现MVC中的M实质上是视图对象模型或很难做成业务对象模型-当然理论上可以做到,但在实际中要做到这一点要付出很大的代价);当您把M理解为业务对象的时候,您在困难重重的压力下不得不选择过程化编码来实现C(控制层).

 

在数据层与视图层的硬性要求下,很难怪不把业务层做简单结构化的(而不是需向对象).

 

 

 

我对上图几个层进行了定义(个人意见只做参考):

视图:只做数据的友好化图形程现和视图逻辑的代码实现(如:某个按钮在某个业务状态下应该怎么样程现)

控制层:对视图的请求指令的合法的处理(如参数的类型验证或用户的权限的合法调用验证),并依据请求从业务层中获取相关的数据返回视图层,且返回的数据不应该存在视图元素(如html代码),同时不能改变用户数据及串改业务数据(它的主要作用是依据相应的请求从业务层截取数据)

业务层:它应正确描述业务的需求过程,对象尽可能职责单一化(就如社会分工一样),通过关系、事件、消息、接口等方式能够使这些对象进行调协工作(良好的封装是一个重要的基础),它更象一个生态化的工作进程,只受到请求(外部刺激)的变更来改变自身

 

数据层:简单的说就是存储用户的原始数据,它不应该存在大量的冗余数据和业务处理过程,另外它只提供业务处理过程中对象状态的还原或恢复(如果说业务层的服务器的内存无限大,处理能力足够强,保证不停机,不中断,我觉得数据层不要也可以)

  • 1
    点赞
  • 1
    收藏
    觉得还不错? 一键收藏
  • 0
    评论

“相关推荐”对你有帮助么?

  • 非常没帮助
  • 没帮助
  • 一般
  • 有帮助
  • 非常有帮助
提交
评论
添加红包

请填写红包祝福语或标题

红包个数最小为10个

红包金额最低5元

当前余额3.43前往充值 >
需支付:10.00
成就一亿技术人!
领取后你会自动成为博主和红包主的粉丝 规则
hope_wisdom
发出的红包
实付
使用余额支付
点击重新获取
扫码支付
钱包余额 0

抵扣说明:

1.余额是钱包充值的虚拟货币,按照1:1的比例进行支付金额的抵扣。
2.余额无法直接购买下载,可以购买VIP、付费专栏及课程。

余额充值