我们刚开始学习架构的时候，首先想到的是分层的概念。经典的分层架构是三层架构。那么，什么是三层架构呢？它包括表现层、业务层和数据访问层；对于新手来说，抽象意义上的三层架构在逻辑上分为三层。这是最基本的三层架构模型。表现层作为系统的界面表现和UI逻辑的作用，也就是说UI（用户界面）属于表现层；、设置、事件等）都写在页面的代码隐藏中，依赖于业务逻辑层。当然，服务器控件支持数据绑定的功能，控件可以通过数据源进行绑定。这节省了隐藏后的代码。因此，我们可以将表现层分为UI用户界面和UI逻辑：UI用户界面的职责只是作为数据输入输出后的展示。UI逻辑的职责是负责业务逻辑层与UI用户界面的数据交互，尽可能让UI逻辑独立于UI技术。其中，UI用户界面的实现方式有很多种，包括ASP.NET、WinForm、WPF、Silverlight、移动Web、智能设备等等。在表现层分离UI页面和UI逻辑的策略中，使用最多的两种模式是MVC模式和MVP模式。MVC模式，即模型-视图-控制器模式，通过视图触发并执行一个操作，调用控制器，通过控制器操作业务层，最后返回模型并显示在视图中。这里的模型可以是领域模型（DM），也可以是数据迁移对象（DTO）。MVP模式，即model-view-presenter模式，有点类似于MVC模式。不同的是，视图和模型在MVP中是完全分离的。在视图中定义了一个接口，显示者通过调用该接口的方法对其进行控制。看法。因此，view和model是松散的，presenter也作为controller，不依赖于UI技术。另外引入了另一种模式PM（PreentationModel），可以说是MVP的一个变种。在PM中，视图没有定义接口。这里的模型只是一个代表视图状态的类，视图中的元素直接绑定到模型上。特性。比如在WPF中，WPF天生就有双向数据绑定机制和事件通知属性机制。所以和WPF、Silverlight等配合特别好。在开始业务层之前，不得不说一个前提。在小项目中，直接让表现层调用业务层就足以解决所有问题。但是，当项目大到需要使用多种表现形式时，比如使用各种UI技术、ASP.NET、WPF、移动设备等，就需要考虑在你的表现层和业务层之间加一层，以便将表现层与业务层解耦，因为业务层作为业务中间件平台，不应该暴露给表现层。这一层就是传说中的服务层。架构图演变为：服务层实际上不执行任何具体工作，其功能是组织各种业务对象，服务层对表现层隐藏了业务层的所有细节，服务器将组件组织在业务逻辑层，并通过数据迁移对象（DTO）与表现层进行交互，从而生成DTO模型。为了实现服务的可重用性，需要使用服务接口，表现层通过指定的接口来访问功能。服务的实现继承了服务接口，而服务的实现则侧重于业务层的调用。对于服务层，常用的方法包括Web服务、.NETRemoting、Rest和WCF技术。我更喜欢将WCF作为服务来使用，因为它可以很容易地配置以达到远程调用服务的目的。服务层消除了两个表示层和业务层之间的耦合。服务层可以实现远程接口，实现多UI技术，甚至多平台通信。当然，增加服务层也有缺点。如果使用WCF服务，会增加系统的调用开销，影响性能。业务层包含系统所需业务流程的实现，并与底层数据访问层进行交互。我们通常把业务层称为业务逻辑层，但我认为业务逻辑层是业务层的一个方面，业务逻辑更侧重于业务逻辑算法的实现。因为业务层还可以包括其他方面。业务层必须包括一个对象模型，它仔细地对业务实体进行建模，并针对客户的所有策略和需求表达业务规则，从而产生域模型。（PS：这里如果不使用领域模型，需要使用业务规则层来验证和控制业务功能上的业务规则）领域模型包括实体的属性定义、方法定义和实体与实体之间的关系。由此看来，UML建模非常重要，通过UML动态图和静态图的描述，可以映射到领域模型。从服务层刚刚提到的DTO模型，需要一种机制将DTO转化为领域模型，因此产生了DTO映射层（DTOMapper）。此外，业务层还包括核心中间件技术，包括第三方组件、工作流引擎等。业务层需要考虑一些与数据访问层交互的设计模式，包括事务脚本模式、表模块模式、活动记录模式和领域模型模式。事务脚本模式就是通过方法来执行业务流程。它是一个过程模型。事务脚本的每个方法都有一个特定的事务脚本。它着重于业务中一系列流程的顺序操作。实现起来非常简单，但是有一个致命的缺点就是会造成大量的重复代码。与事务脚本模式相比，表模块模式具有一定的结构，其思想也很简单。每个数据表都定义了一个业务组件（实体类、实体操作类），在.NET中更多的是使用DataSet作为表。模型数据交互。但它也有一个缺点，就是由数据库驱动，不适合数据表数量多，数据表之间关系复杂的情况。ActiveRecord模式中的对象可以包含数据和方法。它接近于数据表的结构，其对象的执行方法可以包含增删改查操作、校验算法等计算函数。一般来说，领域模型并不太复杂，ActiveRecord模式是一个不错的选择。当然，他也有问题。同样，对于复杂的业务，维护成本也很高，如果需求变更导致数据库修改，需要调整记录对象模型中的相关代码。经典应用：LINQ-TO-SQL和CastleActiveRecord。领域模型模式源于领域驱动设计，是一种以业务为中心的设计模式。它非常适合复杂的业务逻辑。前三种方法使用数据驱动方法。数据驱动方式具有简单的特点，但是当系统达到一定规模后，就会变得难以维护。数据访问层的目的很明确，主要是提供数据持久化功能，包括数据读写，还必须包括事务处理，并发控制等。操作数据库有两种方式：ORM和ADO.NET.ORM可以使用一些第三方的ORM框架来实现，而ADO.NET是使用ASP.NET自带的数据库操作来实现的。不同的数据库有不同的持久化实现，所以这里增加一个存储仓库接口层来适应不同的数据库实现。这里可以使用IOC依赖注入进行数据库选择，也可以使用Unity、Spring.NET、Castle容器等IOC。最后，每一层都可以依赖公共基础设施层。公共基础设施层可以包括Common模块、Logging日志模块、Exception异常模块、Configuration配置模块、DI依赖注入模块、单元测试模块、第三方组件（如NHibernate、Sprint.NET、Castle、Quartz定时任务、etc.)Finalpicture:Summary:项目类型、项目规模、业务需求都会影响系统架构的设计。系统架构不是一成不变的。没有最好的架构，只有更好的架构。多考虑系统的可扩展性。添加一名作者
