系统设计的变与不变（兼答金色海洋的疑问）

系统设计的变与不变（兼答金色海洋的疑问）

首先我们的讨论范围是针对基于数据库的应用设计，还有很多应用不会基于数据库来实现那就暂时不在我们的讨论范围内，
在之前对分层设计的讨论中，金色海洋同学觉得分层没有解决数据库的表字段改动造成的各个层次代码的变动问题，那么
我就以系统的变与不变做题来回答这个疑问。

首先，对系统代码的改动是不可回避的问题，能够适用所有情况的万能组件就我现在看来还没有发现此类非地球物种。那么
在系统设计中哪些应该变那些是不应该变的呢？首先从系统的结构上来说（以ASP.NET为例）。

从以数据库为基础的应用程序上来说，以读取数据为例，整个程序的运行流程我们可以划分为几个阶段：
首先是从页面获取参数->业务逻辑的判断逻辑->数据库操作的逻辑（发送Sql，获取返回数据集）->业务逻辑判断->页面显示逻辑。
然后我们把这些相关的操作一分类，获取参数和页面显示逻辑显然都是在页面上或者和页面关联的类里实现，或者有人通过接口
扩展到了用其他类来实现，我们把这类类归结到一起，就是显示层了，这个层就算通过接口和页面分割了，但是也是和页面高度
耦合的。类似aspx页面和aspx.cs之间可以算作是内容耦合：
比如在展现逻辑需要增加一个要显示的字符串（有可能不是因为数据表增加了列，而是在业务逻辑计算生成的。），那么这个时候
页面就必须做修改。
逻辑判断的类都算在业务逻辑层，为什么会需要业务逻辑层？在网站上的话大多数时候只是简单的读取数据，那么这个层次看似
就很鸡肋，但是我们换一个地方来看，比如，登录、找回密码这些
我们注册一个用户的话，再点击注册后，我们首先会检测用户是否存在，然后要对输入经行验证。再比如登录的时候我们需要对
输入的用户名进行验证，有的时候不光是对数据库里的用户进行验证，有的时候还可能会通过接口去获取其他系统的用户信息来
判断，比如在互联星空上你可以通过注册帐户也可以通过宽带和小灵通帐户都可以登录，那么这些复杂的判断工作就放在业务逻辑层了。
这个层是变化最大的层，我们会尽量把用户的变化都体现在这里，一旦用户的业务逻辑发生了变化，那么就只需要变化这个层的代码。

那么我们要注意一个概念的区别，系统的模型和业务逻辑。系统的模型是对用户需求分析后对系统运行方式的一个规划，数据库的设计
就是根据系统的模型来建立的。
打个比方我们要设计一个网络书店，经过分析我们决定建立一个表，Book来存储书的信息，里面有ISBN啊，书名等信息。结果等我们做
到一半，客户突然说，好像不同的书要存储的属性不大一样，幼儿图书需要标明适合阅读的年龄层次，科技类图书需要标明相关的技术
类型。这个时候你是不是要抓狂？这个时候就是对系统模型要进行就改了。错误在哪里呢？也许就是在需求调研的时候不够仔细，少问
了几个为什么。在对系统模型做更改的时候，包括增减数据库的字段都算是类似的情况，这个时候任何架构都不能保证不对每个层修改
代码。这是必然的。

而业务逻辑呢？什么是业务逻辑，其实也就是逻辑上的判断。设计的不好的逻辑层可能充满if...else...设计得好的也许到处充满着如果设计
模式的经典运用。但是不管是怎么样的设计，业务逻辑层所做的最多的就是判断和数据组织。比如登录。还是用互联星空做例子。

客户的需求说明里：对录入的用户名，先检测是否宽带用户，再检测是否注册用户，都不是再看是不是外省用户，都不是就返回失败

这就是业务逻辑。
如果客户在后来的某个时候修改了登录方式的业务逻辑，改为：先看是否省用户，再检测是否注册用户，最后检测是否宽带用户。

那么我们只需要修改User.Login的代码就可以了。

所以我的观点是，在设计系统的时候要做好需求调研，把系统的模型设计好，留好变动的余量，在商务上尽量说服用户不要作出改变系统
模型的需求变更。这是系统设计的不变。系统设计上的分层，采用MVC就是为了分离责任，为业务逻辑变更带来的系统改变做好准备。在业
务逻辑发生改变的时候不至于打动干戈，这是系统的变。

最后来说说金色海洋同学的新想法。
=============================================================================
表——表单控件。

因为是信息管理方面的程序，是以数据为中心的，一般数据都是要放在数据库里面的，而数据库一般都提供了强大的数据操作功能。

我们为什么仅仅把数据库当作存储数据的容器呢？

我们为什么要忽略T_SQL的强大呢？

所以我的思路是（信息管理方面的程序）：以数据库为主，围绕T_SQL编程。

从现实的世界里面去抽象，我们得到了book，猫、狗，动物这样的类。

那么从数据库的角度去抽象，我们会得到什么呢？我得到了表单控件、分页控件，呵呵。

===============================================================================
金同学这样子的话就直接迈过了业务逻辑，直接从数据到了表现。但是这样子的问题显而易见，无法应对变更，如果客户需要一个数据在进入数据库前需要先经过比较复杂的判断和计算才能入库。那么问题也就来了。首先这个控件无法适应所有的数据库设计，还需要专门的配置表或文件进行支撑，或者干脆就是使用自己的一套来存储数据。最后的结果就是有可能会因为系统的任何一点改动而去修改这个控件。呵呵

=================================================================================
那么如果一个类可以实现一个功能，而类的内部代码又不是很复杂，也是比较清晰，可维护、可扩展的。

那么这个类还有耦合吗？

类的内部就没有耦合了吧，只是在调用这个类的时候才会出现耦合。
=================================================================================
这里就很明白了，类就是要简单，功能单一，越简单的类越容易维护