分享：面相对象的建模（封装业务层）

我一直想写这篇如何构建一完整系统的文章(从需求采集-分析-设计-实施-重构-集成--测试)，目的是从思想上改变编程方式(而不是从某个技术上改变，如果是这样，最终会变成形而向上的东西了)，因为所有的行为都由思想驱使，技术相对是硬性或形式的东西(容易掌握但也容易变化)，思想却是软性而实质东西(不容易掌握但也不容易变化)。

一直没有动手的原因：一来是没有时间（借口吧），更重要的是我不知道如何写，因为很多思想性的东西我不知道 如何用文字或语言来描述(程序员的表达能力公认是不怎么样的)，但在工作中经常看到一些程序员写代码，他们写代码真的很任性。我并不是对他们有什么鄙视或什么不好的意思，我相信他们已经尽自己的所能做到最好的了，我只是希望在这个信息从未如此发达的时代里，他们应该能做的更好(早些年，网络发展初期，在电脑上有个api帮助文档就很满足了)。

在构建我们的业务层的前，须要搞清楚几件事：

1.搞清楚业务(这个对于初级程序可能有些困难)，它是整个系统的灵魂或基础，对业务中的每个过程(场景)需要有一个初步的认识，我习惯对一些比较复杂或想不透的业务过程用图形的方式描述出来 （写文档是一方面，另一面是能过写文档把脑海中的思路理清），如果这块没有搞清楚，我想相信你会在后面死的很难看(我试过，也看过别人试过)，这里我也就不多说了，这里给个建议：不要紧着写代码，三思而后行

2.搞清楚边界(广义上的接口，它是建立在业务之上的)，这个和建表的道理很相近：保持业务功能的单一性(这也是设计模式中的原则之一)

我们这个时代，工作分的越来越细，因为分工协作对处理大型而又复杂的工作很有效率，同样我们的业务层也应该是这样，把每一个实体类当成人一样对待，对每个实体分派不同的功能，然后运用语言自身的特性(interface、abstract、 class、public、delegate)实现之间的交互、组合。依此类推，组件之间，层之间，系统之间。(可以把业务层当成一个组件来做也可以)

这里所说的边界不一定是指代码中的interface或com或其它形式化的定义，它是种思想或概念，当我们熟知它后，就知道在什么时候用interface、abstract、 class、service.....形式化的语法， 而它在我们生活中无处不在(门，窗，电器中的控制器或控制面板，车站，电话.等等)

3.搞清楚什么是视图逻辑和业务逻辑，不要混为一谈，这样就知道那些代码应该放在那里了

4.搞清楚对象与类的关系(这个本是基础知识，本不想写这点的，还是提示一下吧)

下面构建业务模型：

依据业务，整理出业务实体关系图(设计与初步实施的阶段)：帮助我们从整体上观察业务的合理性，减少由于业务需求变化对工作效率的冲击。

这个是我其中一个觉得做的比较理想中的一个项目的业务关系图（这个图已被改过很多次了，在开发过程中会一直的修改，因为客户方的需求很不稳定），箭头代表对另一端的业务实体的引用(或看作地址指针或数据表中的外键)，对于每个实体中具体有什么字段或功能，我们可以在脑海里有个大概就行。这里的关注点在：业务的每个过程是否都可以映射（满足）到业务关系图中的某个或部分结点。

这个工作好象在设计数据库，你可以这么想，但去实施它时，我会先去写Class，而不是去建库建表。为什么啦，在前期需求不稳定的情况下（可以是客户方的问题，也有我们理解上的问题），而另一方面业务层是依赖于数据层的，如果数据层发生了改变，业务层也要改变动(如果视图是同步实施与集成的话，还要改视图层的代码，一般情况下这个阶段不会对视图的逻辑代码的实施，一般是样式效果的设计)，如果我们先从业务层着手的话，上述的问题对我们的代码就影响很小了。在我看到的初级程序员都习惯从数据层下手，最后可能会变成业务层形同虚设或两极分化(在视图层写业务的逻辑代码或在数据层写逻辑代码，早期的桌面时代比较偏重于后者--存储过程+视图)或变成数据访问组件的代替品。当然，如果觉得整个业务层与业务过程都很相近了，十有八九都不会变了，那就直接建表也没有问题。

从业务层下手带来的问题：

如果我们的业务层初步完成时，需要与视图进行集成，出一个演示版本给客户看，以确定最后产品应该是怎么一个样子时，由于这个时候还没有数据库，怎么办;

我的办法是实体类中方法中返回虚拟数据， 更新-》insert (..... ){  new Class(....)  ; return OK ;  } , 查询-》GetObjects(...){  list.Add( new(...) , new(...) , ...  },

可以做一个容器对象当作临时的数据库来用。等到给客户演示完后，核心需求比较稳定的时候再建库（不是一定的，还是依据情况来定）,而且这些代码可以变成业务层的测试代码

设计完业务关系图后(主干部分)，下来就是设计每个实体类的属性和方法(支叶部分)。

这一块主要分成两块，

@业务部分：把业务拆分成多个子过程，对每个过程的思考分析，推断出过程的需要存储的属性<