[冷枫]式开发中的层次划分讨论

注意到用户类构造函数中用了个throw来抛出用户不存在的异常，在下面catch的时候用MessageBox(e. Message);来弹出“用户不存在”的错误。这里其实也是为了演示一个层间传递信息的手段，异常也是一种手段，虽然在这里其实可以有其他方式比如返回值，引用参数之类的直接用一个方法来获得用户是否存在的信息，没必要放在构造里，我这么做只是为了演示传递过程，在后面的有讨论这种用法在分层模式下某种特殊情况的应用以解决一些问题。这个类里又用了DataManager类的一个静态方法IsIn(string Table,string str)该方法其实其实是执行 “select * from Table where str”

这个Sql语句并在返回空的时候方法返回false，否则返回true。一个很简单的方法。这里演示了C层对D层的调用。  

顺便说一句，因为在VS.Net中，项目的名称会默认地成为项目中的namespace，可以通过把所有自动生成的代码中的namespace改为“解决方案名称”来使3个层可以无缝地自由调用。或者在调用的地方using一下其他层的空间名，看个人喜欢了。比如上面的Login.aspx.cs里需要using2个，而User.cs里要using一个。

讲解3：这里的检查用户密码同样用到User类的一个方法CheckPsw（）而这个方法 又用到了IsIn（）这里就不多说了。

大家注意到我们在U层的页面里用MessageBox()方法来弹出对话框，其实这个方法写在PageBase.cs里，是U层的另外一个文件，继承Page类，Login类又继承它，这个方法其实是把Response.Write(“<script>alert(\“”+ msg+“\”)</script>”)封装起来了。   

到此为止，登录结束，例子的实现也说完了。不过只讲了“然”，没有讲“所以然”。下面开始讲“所以然”。

第二部分  

作为对比，我们使用一个不面向对象的，不分层的Asp式的Aspx相同登录作为对比。具体的Asp代码我就不写了，反正登录哪都有。先来看看他们2者发生的遭遇（这是不幸的，却偏偏是经常发生的）：

1、  项目经理突然说“不用SqlServer了，换成Access”（正版费用问题）。看看2边分别发生什么：3层这边（A），把DataManager类里的连接改改（在实际情况下，极可能其实是改它的基类，它本身不用改），Web.config中把字符串换掉就完了。Asp式那边（B），同样要改Web.config，同样要改连接什么的，修改量在这个具体的“小溪”例子上几乎相同，在“大桥”例子上B应该会稍微多改点，不过也不会多很多。但是！请注意一点，我们在修改代码的时候，主要时间和精力不是花在“改”这个动作上，而是花在“要改什么地方”上和“寻找需要改的地方”上。在“大桥”上，B需要花费多的多的时间，对大部分文件进行查找和替换。A则仅仅在数据层里，另外2个层不需要任何修改。从这个角度出发我们想到2点原则：

a)    数据层必须要能够保证数据库的变动（任何结构变动、类型变动）对其余各层的不透明性。也就是数据库怎么变，其他层绝对不应该变哪怕1行代码！（web.config是整个应用程序的配置，虽然在物理上存在于U层的文件夹中，但个人更愿意认为它是独立的不属于任何层的，所以这里不计它）

b)    数据层越小越好（如果没有这点原则，我们把整个所有的东西都放在数据层，那当然数据库变动对外面无影响――因为外面几乎没东西――但是这显然不可行）。而且因为前面我们说了，大部分时间花在“找”上面，你小点，找起来也容易点。

2、  客户突然提出B/S版的不好，要换成C/S版的。对于（B）来说，这是晴天霹雳！！他的所有工作都要重新做，（或者几乎所有工作），虽然他有很多代码还可以用，不过他在未来一小段时间就必须不断在“复制－粘贴”中使用以前的代码。（A）发生了什么？？如果你细心看会发现（A）之需要新建个项目“Windows用户界面”（和前面一样，添加引用，项目依赖），拖几个控件到上面，把控件名字起成txt，ddl，btn，然后把click代码和Pageload代码复制过去，（居然。。。）连1行代码都不需要修改！！！！当然，这是比较极端的例子（win和web都有TextBox，DropDownList，Button3种控件，而且我们在PageBase里定义的方法MessageBox()又刚好和win里面方法同名。。。）不过尽管有这么多巧合我们仍然可以也愿意相信，在“大桥”上，（A）将比（B）少做很多工作。从这个角度出发我们又想到2点类似原则：

a)    界面层应该保证界面的任何变化都不需要修改其他层的内容（不管这个具体的例子把ddl改为另外一个TextBox，或是把B/S改为C/S）

b)    界面层越小越好（理由同上。）

3、  除开了界面层和数据层，（如果你的方案中只有3个层的话）剩下的就都是逻辑层的内容了。所以和前面的相对应，我们可以得出结论：

a)    逻辑层应当不受数据库和界面变动的影响而需要修改。

b)    逻辑层越大越好（因为另外2层越小越好。。。）  

有了最基本的原则，我们应该来讨论下，根据原则，要怎么分层的问题：

1、  PageBase.cs 应该放在哪个层？根据上面的原则，应该放在C层。但是实际上我习惯放在U层，或者放在另外一个（第4个层，通用底层，在比数据层还低的位置）层里。到底放在什么地方，我最开始的做法是在C层，因为按上面归纳的原则，就应该放在C，但是后来一段时间我习惯于“四层式”之后就把它放在通用底层（下简称B层，该层同时也放如本来在D层中的SqlHelper类等，包括原来3层中所有“通用”的类，这里通用的意思是说其他系统也可以用的到而不需要修改，这个层通常不用解决方案名称而用公司、小组名称等作为namespace，在有新项目的时候在建解决方案的时候就可以“添加现有项目”，简单的加进去并不断积累，实践中对提高效率和代码重用有比较大作用。）不过如果只有3层，我现在倾向于把PageBase放在U层。主要因为最近一段潜心研究面向对象的分析设计的心得。说起来又是一大匹布没完，不过我又在前面的“原则”上加1条：“如果某个类，仅为了某层的某种特殊实现而存在，那么它必须放在该层”，比如PageBase是为了U层的特殊实现（B/S实现）而存在，又比如SqlHelper是为了D层的特殊实现（SqlServer数据库）而存在。所以对应的，它们必须分别放在U层和D层（如果不加这条的话按前面他们都该放在C层，因为C层越大越好，而且数据库和界面的变动不需要改动这2个类－虽然它们可能因改动而没有用了，不过还是不需要去修改它们）

2、  Oldjacky曾经和我谈到一个问题：Datagrid中允许作删除操作，但是如果当前仅余下最后一条记录，则不允许这个删除操作！那么该删除应该放在C层还是D层还是U层？我觉得应该从另外一个角度来考虑：

a)    这种“不允许”是“业务规则的不允许”（比如表内的数据表示当前在店里的职员，删除表示职员离开店里－可能去拿货什么的，添加表示职员回来，当柜台只有一名职员时，显然他绝对不能离开去送货），这个时候，此“禁止删除”的操作应该产生在C层。

b)    这种“不允许”是“程序实现的不允许”（比如当这里为空的时候会引起其他地方比如ToString()方法产生“未将对象的引用设置到对象的实例……”的错误，或程序设计者或项目经理的主观愿望希望它“不允许”以此来减少工作量或简化程序）。这个时候，此“禁止删除”可以放在U层（比如上面说的ToString）或D层（比如违反数据库约束）

3、  细心的人可能会发现，前面的登录例子里，用户一共可以获得3种弹出错误分别是“空密码”“密码错误”“用户不存在”，而其中前2个是在U层里做的，“用户不存在”却是在C层里做的（我是指这个字符串）还是开始说的建桥，我这里是用“小溪建桥”来讲解“大江建桥”所以故意在这里转了个没用的圈，就像在计算小溪上这块木板到底够用多少年，其实对小溪没什么意义，只是为了讲解大桥需要而加上去的，毕竟大桥需要这种考虑。我这里假设“用户不存在需要弹出提示”是一种业务逻辑上的需要，而“未输入密码需要提示”则不是业务规则需要（比如实际业务中可以允许空密码，但是项目经理不同意，说一定要密码）在这个登录例子中其实根本没有什么问题，但是在大项目里，如果这个东西不是业务规则的需要，就不应该放在业务层，如果是一种业务规则，就要放在业务层。有助于业务模型与现实实体的衔接，也有益于业务逻辑更好地表现现实实体的特征。

 

到此为止，我再次归纳出我们的最终的原则：

1、  如果某个类，仅为了某层的某种特殊实现而存在，那么它必须放在该层。

2、  数据层应当在保证数据库变化对其他层不可见的前提下尽量小。

3、  界面层应当在保证界面变化对业务逻辑层不影响的前提下尽量小。

4、  如果某个类不是业务规则的需要，就不应该放在业务层，反之亦然。

5、  逻辑层应当在保证数据库或界面变化不会造成自身影响的前提下尽量大。  

以上5点如果发生冲突，在找平衡点的时候，前面的要高于后面的。比如1和3冲突的时候更倾向于使用规则1。

第二部分结束  

有一点应该是“编程代码习惯”和“面向对象”的范畴，不过因为和分层有些关系，所以也说一下。“如果你的代码，自己把它翻译成中文并加必要的标点符号后，其他不懂程序的人看了仍然觉得很乱，那么你很可能层没分好”。比如前面的btn的click：

｛

字符串 用户名是 下拉框 选择值；

字符串 密码是 输入框 值；

如果 密码是 空

   对话框（密码空！）；

否则

｛

   用户 这用户；

   尝试

｛

这用户 是 新的 用户（用户名）；

｝

捕捉（错误）

｛

对话框（错误 消息）；

返回；

｝

如果 这用户检查密码（密码）

{

这用户 设置状态；

响应 重定位（“。。。。。”）；

}

否则

{

对话框（密码错误）

}

｝

代码最好能让不懂的人也能看懂到底在干什么。

最后，oldjacky的Datagrid删除的例子“删除”显然在D层，但是不允许却可能在C或U，如果在U没什么说的了，如果在C，那么这种“不允许”的一个比较合理的实现方法就是在C层里遇到这种情况throw一下。当U层里catch到该throw的时候，禁止删除操作，这样当2个层同时有原因引起禁止时，可以从代码一眼看出这种禁止的来源。类似于前面的2种弹出错误。 

Trackback: http://tb.blog.csdn.net/TrackBack.aspx?PostId=356391