一拍天下项目总结（一）：技术架构
相关索引请查看：一拍天下 项目总结
本文是一拍天下 项目总结第一篇。
一、一拍天下架构图花了半小时，简单画了一下架构图:
阅读之前说明一下：
* 同颜色的块表示一层。
* 实心箭头表示依赖（不太熟悉这个词的，在本文，您可以简单的理解调用关系）。
二、说为什么会选择如此架构入行久的同学，一看就明白：里面有典型的三层架构，同时结合了MVC架构（这里的MVC架构不能完全说是MVC哈）。当时准备做一拍天下项目时，为什么会使用这样的结构呢？
主要原因有二：
1. 三层架构比较熟悉，经过多个项目使用，对三层中各层的职责，以及每一层中各类间的关系有了良好的实践，能够应对项目后期维护和升级的需要，所以一拍天下的底层用了还是选择传统三层架构。
2. 在最上层使用了MVC，主要的原因是应对页面的变化；因为页面是请别人做的，如果生搬硬套成WebForm页面，花费的成本比较大（肯定是可以套的，现在很多公司还在这么做）；与此同时呢，如果加一个页面，页面稍微有点变化，我们这群只会搞业务系统开发不怎么懂UI的人很容易束手无策。
就着第2点，曾经写过MVC的优劣，感觉总结得还可以，摘一段关键文字过来：
完成了 一拍天下后，最大的感触就是：
1. 使用了Razor视图引擎，完全控制Html展现；
2. MVC完美的融合jQuery库；
3. 页面变得很轻、清爽，不像以前的WebForm页面一堆ViewState。
本文不讲MVC，若没有用过的同学可以简单查看： 4. 数据访问层(DAL)
这一层职责很简单，负责与数据源（各种异质数据来源）进行通信。此层的类也有相对比较严格的约束：
a. 没有类间调用。即ADAL不能与BDAL有任何调用关系。
b. 一般情况下，一个DAL类对数据库的一张表进行操作（一张表通常是代表着一个业务对象），一个DAL类一般也会对应一个Business Model类。
c. DAL层类只能被BLL层调用，不能被更高的层调用（原因不写了哈）。
d. DAL层的所有类均为静态类。
e. BLL层的一个类里面的公有方法，不可以被本类的任何方法调用，只能被上层调用；私有方法，可以被本类方法调用。
BLL层类的职责这样严格划分，保证了DAL类间职责明确，方便后期新增和修改业务时，很快定位到具体到DAL层的哪一个类。
5. 业务逻辑层(BLL)
BLL层主要负责原子业务逻辑。什么是原子业务逻辑呢？是自创词汇，可以理解为BLL类的每一个方法只能代表只能做一件事。比如新建一个公告，可以认为是一个原子方法；但如果在“新建公告”中加入权限验证，那么这个方法就再怎么单纯，也不具备原子性了。
为什么要让BLL层的方法具体原子性呢？
我们主要是因为方便复杂业务的封装，以及考虑代码的重用性。举一个形象一点儿的例子：房子是用砖和瓦砌成的，这个砖和瓦就是我们所说的原子，用他能做出各种造型的房子来。之所以能做得出来，是因为砖的功能很单一（都是同一个形状），能被随意的组装。如果需要砖了，不需要重新去设计一个砖模型（新建一个BLL方法），只接把原来的砖再生产几车就可以了（new 一个对应的BLL类，调用此方法就可以）。
相对于DAL层，BLL层的职责和约束也相对复杂。由架构图，我们可以得出：
a. BLL层可以被Fac层和MVC的Controller调用；
b. BLL层可以调用DAL层，并且可以其他业务对象对应的DAL，比如ABLL不仅可以调用ADAL类，也可以调用BDAL类。
注：其实有段时间，我们也不允许ABLL调用BDAL，但是发觉这样会把所有的业务组装，都放到了Fac层或更高层。导致FAC层、上层很臃肿；但事实上，在现实中，一个BLL层的一个原子方法可能需要几个步骤组成，具体例子暂不列举，细想便知。为了让BLL层干自己的事（你自己的原子方法总得自己组装吧，不能什么都让上面帮你做啊），为了减轻上层的压力，强化各层职责，所以我们允许BLL的类调用其他类的DAL层方法。
c. BLL 层类间不存在调用（即不存在ABLL调用BBLL、CBLL），以保证BLL方法的原子性，同时也避免循环引用。
d. BLL层的一个类里面的公有方法，不可以被本类的任何方法调用，只能被上层调用；私有方法，可以被本类方法调用。
6. FAC层FAC为组装层，复杂的业务在此层组装。该层源于对Facade模式的理解，即外观方法。一个得复杂的业务，可能需要BLL层的多个类的业务方法才能完成。但是对外呢，只提供一个简单的调用方式。它的作用只要是封装了实际业务的复杂性。
我们对FAC层分配的职责如下：
a. 供MVC框架的Controller调用；
b. 可以调用BLL层的多个BLL类实例方法；
c. 不允许Fac类间调用（如图，MSERVICE与NSERVICE不能互相调用）。
d. FAC层的一个类里面的公有方法，不可以被本类的任何方法调用，只能被上层调用；私有方法，可以被本类方法调用。
f. 异常处理（try-catch），并返回友好提示。
7. MVC层
主要负责接收前端的请求，并下发给下层处理，最终展现给用户。在使用MVC架构的同时，根据实际情况，也有所变化。
7.1 一拍天下的Model 职责与MVC中的Model职责不一致。这里说是MVC层，本身不准确，但架构这种东西一般不会完全按着已有经典架构来，每一个项目通常有自己特有的架构方式。
一拍天下架构 上层使用MVC构架，准确的说也不是完全按照MVC的模子来的。主要体现Model，MVC中的Model的职责至少有二：
a. 业务实体，和这里的架构基本一致；
b. 处理业务请求。（相当于一拍天下架构的BLL层及DAL层部分）
其次，
c. 微软MVC引用模板验证机制，即在Model本身验证自身的属性是否符合规则(一拍天下也使用了此特性)。
回到一拍天下架构，Model层的主要职责比较单纯，它包括上面a和c两点。至于图中所示：还有ViewModel和Param Model 分别是因为MVC视图显示的需要、参数封装的需要，总体说来，我们的Model层没有MVC中Model的业务处理职责；业务处理职责已经作了细致的划分，在本文前面的内容已经说明。
注意：关于MVC这里不作细究，具体可以参照 MVC 学习索引 ，简单了解。
7.2 再说MVC层的主要职责其实，这里说是主是MVC中Controller的职责。
a. 调用FAC层和BLL层完成最终业务组装。
b. 异常处理（try-catch），并返回友好提示。
c. 不允许Controller类间调用；同时也不允许本类间公有方法进行调用。
四、一拍天下架构总体说明
总体说来，
1. 一拍天下的架构在每一层，要求本层之间的类不能互相调用，本层类里面的公有方法不能互相调用，使类、公有方法职责明确化。
2. 上层不能跨层调用较低层，使层的职责明确化。这里有一个特殊,MVC层能跨层调用BLL层（因为它们中间有一个FAC层），事实上，从FAC的责任来看，它也是对业务的封装，而MVC层也有封装业务的职责，FAC是将很复杂的业务进行封装后直接供MVC层调用，这样能瘦化MVC层；在一定意义上说，FAC是比BLL层更为高级的大业务原子层（它由各种BLL原子组装），故您可以视为高级BLL层即可。
3. 低层不能调用高层。
4. 异常处理机制在MVC层和FAC层，并在这里给用户友好提示。原因很简单，只有在组装层最全面的了解问题出在哪儿，给用户何种提示。
写一个结束语吧：其实做一拍天下架构时，很多时候都是在划分职责问题，层、类、方法的职责。面向对象里面非常关键的设计理论就是要考虑对象的职责，"不能在衣柜里放马桶"。
谢谢阅读，欢迎指正！
欢迎关注 一拍天下 ！
