突写，再谈面向对象

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

 

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

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

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

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

 

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

 

 

 

我对上图几个层进行了定义（个人意见只做参考）：

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

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

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

 

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