微软应用架构指南(第2版)

　　 《微软应用架构指南(第2版)》为架构师和开发人员提供有关基于微软平台和.NET框架进行应用程序架构设计的一些指导。《微软应用架构指南(第2版)》分为四个部分：第一部分“软件架构和设计篇”提供了对底层原则和模式的总结，第二部分“设计基础篇”提供了有关设计解决方案分层、组件及服务的指导原则，以及处理有关质量特性和横切关注点的一些指导原则，第三部分“应用原型篇”提供了针对典型应用程序类型的一些特定指导原则，最后，附录提供了微软平台和.NET框架技术及其特性的概览。
　　

序g
序二
前言
导言
软件架构和设计篇
第1章 什么是软件架构
1.1 为什么架构很重要？
1.2 架构的目标
1.2.1 架构风景线
1.3 架构设计的原则
1.3.1 关键设计原则
1.3.2 其他资源
第2章 软件架构的关键原则
2.1 概览
2.2 关键设计原则
2.3 关键设计考量
2.3.1 确定应用程序类型
2.3.2 确定部署策略
2.3.3 确定合适的技术
2.3.4 确定质量特性

　　做.NET 或是微软平台的架构设计既简单又困难。说简单的理由是，微软提供的产品往往考虑全面，容易上手，并且文档丰富。说困难的理由是，微软往往没有什么权威性的“指南”推荐说A方面可以用X 技术，B 方面可以用Y 技术（比如JAVA 开发流行的Struts2+Spring+Hibernate 框架），甚至更大的问题是（特别是前几年）微软没有提供针对一些常见技术（比如ORM/MVC/AOP）的“官方”实现。这就使得.NET 平台的一些系统的架构五花八门，有的架构师愿意自己写一些轻量级的实现，有的则愿意使用从JAVA 移植过来的一些实现，比如NHibernate、Spring.NET 等。
　　而现在，《微软应用架构指南》这本书针对前面提到的问题提供了一个不错的答案，它针对不同的技术点或应用场景或应用程序的类型，给出了一些微软平台（甚至开源界）可用的或是推荐的一些技术或框架，还介绍了何时适用这些技术和框架及在处理这些点的时候应该考虑的问题。更重要的是，微软在近几年确实针对很多技术提供了微软自己的实现，比如ORM 框架ADO.NET EntityFramework、SOA 框架WCF、MVC 框架ASP.NET MVC，等等。对于那些对框架的选择头疼（想引入非官方框架却又怕遇到难以解决的问题）的技术人员和架构师来说确实是好消息。
　　在翻译和阅读本书的过程中，译者有几点体会和读者一起分享。
　　（一）如何使用本书？
　　作者不止一次提到本书是一个大纲而不是大全，本书的重点在于介绍架构设计的方法学；架构设计中要考虑哪些方面的问题，这些问题有哪些技术可以解决或实现；微软平台有哪些应用程序类型，这些应用程序有哪些技术可以实现；应用程序怎么进行拆分，拆分后的每一部分可以由哪些技术来实现。也就是说本书主要解释的是有哪些“东西”以及这些“东西”可以由什么来实现这两个问题。对于后者，由于篇幅的关系只能列出技术或方法的名字然后提供一个参考链接。
　　我们知道，对于架构设计来说，其中包含的技术、框架、原则不太可能靠几小时或几天来彻底了解透彻，应该通过阅读本书来了解我们手里有哪些“东西”，这些“东西”适合什么样的应用场景。如果在之后架构设计的过程中你发现可以并且适用这个技术，可以进一步深入阅读和研究这些扩展资料。个人认为应该这样阅读本书：首先把自己不知道的知识点通读补全，然后可以把本书当作一本参考书，在实际架构设计的过程中根据自己的记忆能回忆起“这个问题好像在书中提到过可以用XXX 来解决”，那么再拿起本书找一些书中列出的参考链接或在网上找一些参考资料进一步学习。
　　（二）读不懂怎么办？
　　译者认为本书针对的是架构师和有架构经验的开发人员，如果读者刚接触程序开发或从未对完整的系统或是系统的一个模块进行过架构设计（所谓架构设计可以理解为设计一个系统中需要哪些组件及各个组件之间如何协同工作，以及确保这个系统达到预计的质量和需求需要做的工作），那么确实会比较难理解本书，在经过了自己的实践尝试之后回头再阅读本书您会发现不再是完全看不懂了，而是可以知道自己要了解的那部分内容可以在哪里找到答案。其实，即使是经验丰富的开发人员和架构师也可能会遇到不理解的内容，因为微软平台的技术是如此广泛，我们的工作往往关注的是某个平台的开发，比如桌面应用程序、移动应用程序、网站等，而不会面面俱到，因此您完全可以不必介意读不懂哪部分内容，有的只需要了解即可。
　　对于每一个方面，本书会列出许多需要考虑的要点，需要实现的步骤，能使用的技术。列出的这些条目源自许多技术专家在针对这方面进行架构设计时积累的经验，如果读者进行过这样的考虑甚至是尝试，就会容易理解作者想表达的意思，甚至会在读到这个条目后暗自叫好。译者就有这样的体会，由于自己做过一些横切关注点的框架实现，在阅读横切关注点一章时，看到和自己的思考吻合的一些条目时，才能体会到小小的一行条目包含了作者大量尝试后的经验和体会（十几个字归纳了译者经过几小时甚至几天的实践得出的结论）。相反，对于一些自己不熟悉的技术，确实也难以彻底理解每一个条目。因此，如果读者正在从事相关架构设计或开发的话，可以再仔细阅读每一部分内容下的一些子条目，或许你可以有新的发现。
　　（三）如何进行架构设计？
　　如何进行架构设计是本书讨论的重点，译者认为最主要的是权衡、渐进两点。所谓权衡，就是我们在进行架构设计的时候首先需要找出我们的目标包括哪些因素，每一个因素又需要达到怎么样的指标；然后根据这些因素的重要程度结合我们实际情况（软硬件、成本、资源）等等权衡得出一种比较适合的架构。所谓渐进就是架构设计和软件开发相似，应该是一个迭代的过程，每一个系统都会经历从少到多，从简单到复杂的过程，我们的架构往往只需要满足当前的负载即可，过于超前的考虑会带来不必要的成本，随着时间的推移，我们可以通过不断演化架构来满足新的功能和负载需求。其次，在为一个大型系统做架构设计的时候，可以先考虑把这个架构划分成独立的关注点，然后针对每一个点，分别进行方案制定、技术评估、开发测试等过程，最后把每一个点的方案合并在一起组成一个完整的架构。另外，对于架构设计中引入的技术根据项目的性质可以采用不同的策略，如果是一个内部项目，面向少量用户并且不会是一个长期的项目，那么可以考虑引入一些新技术、新框架，如果是一个外部项目，面向大量的访问并且需要保持数年的稳定，那么一定要慎用一些未经验证的新技术，慎用一些我们不能掌控的框架，否则一旦出现问题我们很难在短时间解决。
　　本书的前半部分（从第1 章开始到第19 章）由我翻译，后半部分（从第20 章开始到最后）由我的同事高翔翻译。由于时间和能力的关系，翻译中肯定有很多不足，欢迎大家提出自己的意见和建议。同样欢迎读者和我探讨有关架构和设计的问题，我的邮箱是yzhu@live.com。
　　朱晔
　　2010年10月
　　

　　在那些搞笑的开发人员之间有个常讲的老玩笑，你只要用“视情况而定~~”回答技术问题，别人就会认为你是一名架构师。
　　问：“我解决方案中实现身份验证和授权的最佳方法是什么？”，答：“视情况而定”；
　　问：“我应该怎样实现我的数据访问层？”，答：“视情况而定”；
　　问：“我解决方案的UI 应该使用什么技术”，答：“视情况而定”；
　　问：“怎样才能使我的应用具有可伸缩性”，答：“视情况而定”。
　　实际上这些真的需要视情况而定，每个解决方案最终是不同的，技术和非技术等许多的因素都会或大或小影响解决方案的架构和设计。开发人员和解决方案架构师的工作在于平衡由业务、最终用户，公司的IT 环境和管理基础结构、经济环境和用于构建方案所使用的技术和工具等等所提出的需求和限制，而这些需求和限制通常是相矛盾的。
　　然而有意思的是，随着系统中新机会的产生和新要求的提出，这些需求和限制不断演化，业务规则的变化和新业务领域的拓展可以影响新的应用程序和现有的应用程序。随着时间推移，用户渴求更丰富、更一致、更综合的用户体验，随之就会产生新的需求。或可能会出现新的IT 基础结构技术，以减少成本或提高可用性和可伸缩性。与此同时，会不断出现新的技术、架构和工具，旨在降低开发成本，提供以前较难实现的应用。
　　由此可见，要理解这些并同时要开发一个合时合算的有效解决方案是一件不容易的事情。这要求开发人员和架构师要考虑所有相竞争和重叠的因素（其中有一些是非技术的）占的比重，然后将它们做出一个较合理的权衡。试图将太多因素整合在一起，可能会导致解决方案过度开发并且非常复杂，这样的解决方案需要花很长时间来构建并且可能仍然不能按时提交，或不能保证长效性和灵活性。另一方面，如果考虑太少因素，也有可能会形成一个作用有限的，缺乏灵活性的、不易升级的临时解决方案，这样的解决方案难以发展也不能很好地扩展。总而言之，开发人员和方案解决架构师通常是游走在“黄金方案”和“即时方案”之间。
　　对我来说，架构就是利用现有的技术和工具来创造尽可能多的商业价值，一方面关注现有业务所提出的需求和限制，另一方面着眼于未来通过可伸缩性、灵活性以及可维护性等方面最大化价值。准确解读架构原则和模式，有利于开发人员和解决方案架构师更好地理解和关注架构设计的整体设计过程，以及可能会对整个方案的成败产生重大影响的设计问题。拥有这些知识，他们可以做出更合理的决策，更好地平衡相竞争或重叠的需求和限制，并确保解决方案不仅能达到或超过业务目标，同时还能节约成本、兼具可扩展性、可维护性以及灵活性。
　　您可能注意到，我同时提及了开发人员和解决方案架构师，我认为两者都可以在充分理解了本指南讲述的架构模式和架构原则后获益。有些人可能认为细节实现比不上整体设计重要，但依我的经验看来往往不是这样的。一些小的决策随着时间的推移会累积。实现层次的一些细节可能会对解决方案的整体架构（可伸缩性、可维护性以及灵活性等方面）产生重大的影响，因此开发人员和解决方案架构师都需要充分理解实现细节。此外，开发人员和解决方案架构师应该达成共识，可以使两者之间更好的沟通，也有利于工作的开展。
　　该指南旨在提供应用架构和设计原则和模式的概述，以帮助您做出更好的决策和构建更优秀的解决方案。该指南编排为可以从头到尾阅读，也可作为参考资料从文中直接选取您需要的章节来阅读。
　　该指南的前半部分主要介绍能应用到所有类型解决方案的普适架构原则和设计原则，后半部分主要关注常见应用程序类型（例如Web 应用程序、富客户端应用程序、或是移动应用程序）以及描述了每一种类型的典型架构和关键设计考量。有可能您的特殊解决方案不能直接和某个应用方案匹配，但是它们能为您提供一个基准架构，您可以在这个基准架构之上演化成您的特殊解决方案。该指南还提供了一些有关如何找出您架构中关键元素的建议，这样您就可以不断对它们进行改进。该指南主要关注基于微软平台和.NET 框架开发的解决方案的指导，因此包含了提供相关技术和工具细节的参考文章和资源。不过您会发现底层的原则和模式适用于任何平台。值得注意的是，本书并不是一个针对应用架构和设计面面俱到的参考——如果是那样的话可能就需要更大的一本书或者分成多卷了——因此本指南旨在提供针对最重要主题的概览以及一些链接可以进一步扩展更细节的或更深的内容。
　　应用架构和设计领域是动态的不断变化的。在过去基于这些基本原理已经产生了很多成功的解决方案，在将来这些基本原理同样能为我们所用。但是我们仍然应该期望变革的步伐不会停滞，不管是在技术方面还是新的设计方式方面。微软平台和.NET 框架、一系列技术以及这些技术支持的各种应用场景既深入又广泛，并且会越来越深入和广泛。不过，我们不需要等待将来的东西。现在就可以开始构建令人称道的有价值的解决方案，希望本指南会帮你完成这个工作。
　　David Hill
　　模式和实践团队
　　2009 年9 月
　　

　　序一
　　在使用我们自己的技术来构建微软产品，以及平时和客户及合作伙伴一起工作的过程中，我们已经形成了一套关于如何使用我们的技术为应用架构及设计模式和原则去应用最佳实践的最佳实践。这个指南对开发人员和解决方案架构师来说都非常有用。我们从内部实践、外部专家、客户和其他社区人员中收集了一些指导原则，并整合成这本《微软应用架构指南》供大家分享。
　　该指南旨在帮助解决方案架构师和开发人员在微软平台上更有效地设计和构建应用程序，以及协助他们在新项目初期做出关键决策，同时提供特定主题的内容来帮助架构师和开发人员改善既有的解决方案。有超过25 个外部专家和客户为该指南做出了贡献和进行了审阅。
　　通过思考一个解决方案的架构模式和原则、质量特性及横切关注点等方面，我们可以快速得出一个基准应用架构和相关的技术、模式及指导原则，来帮助您构建解决方案。然后我们可以使用该指南来确定应用架构中的关键点，这样您就可以根据应用场景来完善应用架构。
　　本指南包含了Web、富客户端、RIA、移动、服务应用程序等常见应用程序类型的参考应用架构，以及有关质量特性、横切关注点、设计方法的一些指导原则，它可以帮助您设计和完善解决方案架构。
　　我们有信心，《微软应用架构指南（第2 版）》可以帮助您选择正确的架构和技术，选择恰当的模式，以便帮助您做出更有效的设计决策。
　　S.Somasegar
　　微软开发部高级副总裁
　　
　　序二
　　本领域各种各样的书籍、文章、白皮书都表明，应用架构是一个富有挑战性的主题。开发人员和架构师仍然很难理解基于微软平台的架构和最佳实践设计。最初的《.NET 应用架构：设计应用程序和服务》已经在这方面做了很多出色的工作，但是这书写于2002 年。
　　为了应对从那以后出来的新技术，J. D. Meier, David Hill 和他来自微软模式和实践的团队已经建立了一套新的应用架构指南，该指南为设计运行于微软平台下的应用程序和服务提供了深入的指导，并且是基于最新最佳的实践技术。《微软应用架构指南第2 版》的诞生，旨在帮助解决方案架构师和开发人员在微软架构平台上设计更有效的应用程序。该指南不仅涵盖了.NET 框架、微软平台以及它们相关的主要技术和特性，同时它还提供了平台无关的、面向模式的和基于原则的指导，以帮助您为应用程序打好坚实基础。
　　该指南基于一些提供结构的关键架构和设计原则。其中包括有关确定和处理关键工程决策的指导原则，指南还提供了对质量特性、横切关注点的解释，以及诸如性能、安全性、可伸缩性、可管理性、部署、通信等构成您应用架构的性能。
　　指南还介绍了每个解决方案架构师在元级别应该考虑的逻辑层和物理层。对于每一个逻辑层和物理层，都介绍了其关注点、功能、能力、常见设计模式及技术。然后在这些基础之上，进而介绍相关的原则、模式和实践，最后提供了公认的应用程序典型来演示常用应用类型，并介绍其目标场景、模式和它所包含的基础结构。
　　整体而言，该指南建立在微软专家、微软合作伙伴、客户以及社区里的其他成员的综合经验及知识之上。它将帮助您理解我们的平台，选择恰当的架构和技术，使用经过验证的实践和知识来构建应用程序。
　　Scott Guthrie
　　微软.NET 开发平台副总裁