购买链接：http://www.china-pub.com/197209

 译者序

做.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月