如何写一篇应用架构论文

一般来说，三层架构实际上是将整个业务应用分为表示层、业务逻辑层和数据访问层。

三层架构在客户端和数据库之间添加了一个“中间层”，也称为组件层。这里说的三层体系不是指物理上的三层，或者简单的放三台机器或者一个三层架构，而且也不仅仅是B/S应用才是三层架构，三层指的是逻辑上的三层，即使这三层放在一台机器上。

普通三层:数据访问层DAL:用于实现与数据库交互和访问，从数据库中获取数据或将数据保存到数据库中的部分。业务逻辑层BLL:业务逻辑层是承上启下的，用于对上下交互的数据进行逻辑处理，以达到业务目标。表示层UI:主要实现与用户的交互，接收用户请求或返回用户请求的数据结果的展现，而具体的数据处理则交给业务逻辑层和数据访问层。业务实体模型:用于封装实体类的数据结构，一般用于映射数据库的数据表或视图来描述业务中的客观对象。模型分离是为了更好的解耦，更好的发挥分层的作用，更好的重用和扩展，增强灵活性。通用:一个通用的辅助工具类。

工程模式:工厂方法模式，也称为静态工厂方法模式，属于类的创建模式，通常根据一个条件(参数)返回类的不同实例。

工厂角色(创建者)

是工厂方法模式的核心，负责创建所有具体产品类的实例。工厂类可以被外界直接调用来创建所需的产品对象。

抽象产品(产品)

是所有特定产品角色的父类，它负责描述所有实例拥有的公共接口。

特定产品角色(具体产品)

从抽象的产品角色继承而来，通常有多个角色，这是工厂方法模式的创建目标。工厂类返回角色的特定产品。

通常情况下，客户端不直接与数据库交互，而是通过COM/DCOM通信与中间层建立连接，然后通过中间层与数据库进行交换。

一个完善的三层结构的要求是:修改表示层不修改逻辑层，修改逻辑层不修改数据层。否则很难说你的应用是多层结构，还是层结构的划分和组织有问题。不同的应用有不同的理解，这是一个概念问题。

从概念上讲，MVC系统中的模型可以分为两类――系统的内部状态和改变系统状态的动作。模型是所有业务逻辑代码片段所在的地方。本文为该模型提供了业务实体对象和业务处理对象:所有业务处理对象都是从ProcessBase类派生的子类。业务处理对象封装特定的处理逻辑，调用业务逻辑模型，并将响应提交给适当的视图组件以生成响应。业务实体对象可以通过定义属性来描述客户端表单数据。所有的业务实体对象都是从EntityBase派生的子类对象，业务处理对象可以直接读写它，不需要与请求和响应对象进行数据交互。业务实体对象支持视图和模型之间的交互。实现将“做什么”(业务处理)和“如何做”(业务实体)分开。这样可以实现业务逻辑的重用。由于每个应用的具体业务不同，这里不列出具体的代码示例。

MVC(模型-视图-控制器)是一种设计模式，可以用来区分域对象和UI表示层对象。同样是在架构层面，相同的地方是他们都有一个表示层，但他们的区别在于另外两层。三层架构中没有定义控制器的概念。这是我觉得最不一样的地方。而且MVC并没有把业务的逻辑访问看成两层，这是采用三层架构还是MVC构建程序的主要区别。当然了。三层中也提到了模型，但是三层架构中模型的概念和MVC中的不同。“三层”中典型的模型层由实体类组成，而在MVC中，由业务逻辑和访问数据组成。

用ASP NET中的MVC框架编写，具有极好的扩展性。它可以轻松实现以下功能:①实现一个模型的多视图；(2)采用多个控制器；③当模型发生变化时，所有视图都会自动刷新；④所有控制器将相互独立工作。这就是MVC架构的优势。您可以通过稍微修改以前的程序或添加新的类来轻松添加许多程序功能。过去开发的很多类都可以重用，但是程序结构根本不需要改变，类之间相互独立，方便了群体开发，提高了开发效率。下面讨论如何实现一个模型，两个视图和一个控制器程序。模型类和视图类根本不需要修改，和上一个一模一样。这就是面向对象编程的优势。对于控制器中的类，只需添加另一个视图，并将其与模型相关联。这种模式下视图、控制器和模型之间的示意图如图2所示。也可以实现其他形式的MVC，比如一个模型、两个视图和两个控制器。从上面可以看出，通过MVC架构实现的应用具有极好的可扩展性，是ASP NET面向对象编程的未来方向。

MVC的缺点有:(1)增加了系统结构和实现的复杂度。对于一个简单的接口，严格遵循MVC，将模型、视图和控制器分离，会增加结构的复杂度，并可能产生过多的更新操作，降低运行效率。(2)视图与控制器连接过紧。视图和控制器是相互分离的，但又是密切相关的。没有控制器的存在，视图的应用非常有限，反之亦然，阻碍了它们的独立重用。3)视图对模型数据的低效访问。根据模型的操作界面，可能需要多次调用视图才能获得足够的显示数据。不必要的频繁访问未更改的数据也会损害操作性能。(4)目前一般的高级接口工具或构造器都不支持MVC架构。改造这些工具来满足MVC的需求，建立单独的组件，成本非常高，这使得MVC很难使用。

三层架构将代码按照功能分为三部分，每一部分解决自己负责的流程。三层架构的功能是控制大型web程序的结构，使它们易于管理和扩展。

在设计UI的时候，我们不需要关心逻辑和数据的问题，我们只需要留下放置数据的相应位置。设计修改的时候只需要解决HTML的结构，代码看起来干净利落，做起来也干净利落。

UI直接把程序逻辑的任务扔给BLL，BLL开始构建具体的实现细节。BLL的创造依赖于商业。例如，一个文章系统，BLL _文章，意味着它是用来处理文章的。BLL _ article可以为UI提供一个文章列表的记录集，显示在UI的预留位置。当BLL粒子需要从数据库中获取数据时，它将任务扔给DAL层。

DAL层负责处理数据库。它从BLL获取参数，组织有效的SQL，建立数据库连接，执行SQL进行更新或获取，并将返回的数据交给BLL。

每一部分业务都集中在一个UI-BLL-DAL的链条上，从上到下一目了然。至于如何便于管理和扩展，后面会举例分析。

复杂的生命形式必然有复杂的生存法则。如果想在自己的项目中应用三层架构，需要用点心来体验应用规则。

我对三层架构的理解还不够深入，这几篇文章算是一个启发也不错。在阅读的时候，不要局限于我所构想的规律，而要在具体的应用中去实践，根据具体的情况找出自己的规律。如果你有感觉，记得写下来。这种感觉是进步的机会，但不一定是最终的结果。如果你有感觉，你可以应用它，发现它的优缺点并继续改进。

三层架构比双层或单层架构有更大的优势。三层结构适合小组开发，每个人可以有不同的分工，合作可以让效率翻倍。在开发两层或单层应用时，每个开发人员都要对系统有深入的了解，这就要求能力很高。开发三层应用时，可以结合各个领域的人才，只需要少数人对系统有充分的了解，一定程度上降低了开发难度。

三层架构属于瘦客户端的模式，客户端只需要更小的硬盘、更小的内存、更慢的CPU就能获得不错的性能。相比之下，单层或者胖的客户对人脸设备要求太高。

三层架构的另一个优点是可以更好地支持分布式计算环境。逻辑层的应用可以在多台机器上运行，充分利用网络的计算功能。分布式计算潜力巨大，远比升级CPU有效。

三层架构最大的优势就是安全性。客户端只能通过逻辑层访问数据层，减少了入口点，屏蔽了很多危险的系统功能。

石明远回答道