标签：架构
在这次的项目中，接触了“新”的底层架构。
做项目两个多月以来，对底层架构，脑中只有一个大概轮廓，一直以来都没有行动下移，把这架构落实到图上。
近日，抽出一些空儿，画画图。看看这个被大牛们吹捧的架构，到底是怎么回儿事。
不管这个架构怎么变，它都来源于经典三层UBD。从整体看，不同之处在于，U层在调用B层的时候，是通过WCF。WCF，用于分布式，在这篇文章我们暂且对它忽略不计。然后就只剩下UBD，U层在这里我们也先对它“不闻不问”。这样就只剩下B层和D层。所以从整体看，这个架构很简单。
在设计模式中抽象工厂加反射一章，让我们学会了，通过修改配置文件灵活更换具体的D层实现类。那么在这次的架构中，它的每一层都有接口，具体实现类，还有工厂。从而保证我们灵活的更改具体的一个系列的实现类。不论是B层的还是D层的。
所以，你只要对三层和抽象工厂+反射足够熟悉，那么这个架构一定难不倒你。
D层：封装了对数据库中进行CRUD的操作，之前是通过ADO.NET，这里是通过EF。在用EF的时候，不管是进行何种操作，都得通过EF的上下文实例。（据说，为了保持数据一致，在用户的一次请求中只能有一个上下文，所以通过DbContextFactory来管理）。
B层：是业务逻辑层，主要和用户功能对应，而用户功能无非也是添加，修改，查询，删除等操作。一种是B层和D层一一对应。也就是B层的一个类的所有方法只会对一个实体操作。另一种是B层就相当于外观层，每个类中的方法都可以组合D层对不同实体的操作。（现在还不知道孰优孰劣）。
不管B层采用哪种形式，之前的时候，B层里的每个类在调用D层方法的时候：第一步都是声明D层接口，第二步就是通过工厂的方法给这个接口赋值。
而且，针对EF，只有执行SaveChange方法之后，添加，删除，修改操作才会持久化到数据库这个相当于一个公共的操作，它是属于上下文实例的。
对于上述两部分公共内容，我们把它们封装在DbSession中方便管理。
所以从横向看，就是下图：
纵观：（继承和实现）
我们将每个层用到的公共方法进行封装，让子类继承基类，使代码复用。我们的项目包括多个系统，对于所有的系统公共的方法，则是级别最高的父类。而对于系统内部公共的方法，可以封装到稍低一级的父类。继承，可以是类继承抽象类，也可以是接口继承。运用接口继承，主要是规范约束。
子类（具体的实现类）在继承父类的同时，也实现它的接口。这样当子类想扩展新的方法时，因为别的层依赖于接口，而不依赖与具体实现。这种情况下，需要先在子类实现的接口中定义方法，然后再在子类中实现。
总结
从宏观来看，这个架构灵魂的东西还是没有变，三层的思想，运用抽象工厂应对变化，面向接口编程。变的是，这个架构站在整个平台的角度，进一步的封装公共东西，同时灵活运用继承和实现来更好地达到复用和扩展的目的。同时部分类的使用，将一个庞大的类，分成几部分，提高代码可读性。
以上是我从这个架构中积累的。说实话，对于这个架构具体的好处，以我的功力，还不能说出一二。现阶段，就先宏观了解一下各个层各个类的调用关系，去接受它。然后再在不断地学习和实践中解答为什么要这样设计。
最后附上UML图一张。点击查看大图
标签：架构
原文地址：http://blog.csdn.net/u010924834/article/details/43527761
