.NET 2.0模式开发实战（Web开发大师力作）
基本信息
推荐阅读
内容简介回到顶部↑
本书阐述了应用于.net 2.0框架的设计模式，重点以c#语言来演示应用各种模式。书中的主要内容包括面向对象编程的实质、模块化和异常、测试驱动开发、基本设计模式、应用于架构策略的设计模式、序列化和持久化等，同时针对测试、模式和重构，阐述了相关联的面向对象编程。
本书适合高等学校计算机相关专业师生，以及从事.net程序设计的程序员阅读。
本书适合高等学校计算机相关专业师生，以及从事.net程序设计的程序员阅读。
作译者回到顶部↑
本书提供作译者介绍
Christian Gross是一位经验丰富、多才多艺的软件顾问，客户包括微软、戴姆勒－奔驰等大型公司。他精通各种微软客户端/服务器技术。除本书外，他还撰写了畅销书Ajax Patterns and Best Practices，并与人合作撰写了许多ASP、SQL Server、Windows编程方面的技术图书。
.. << 查看详细
.. << 查看详细
目录回到顶部↑
第1章 面向对象编程的实质
1.1 理解类型
1.2 模块化与可重用代码
1.3 利用作用域控制访问
1.4 理解继承
1.4.1 class与struct在继承上的区别
1.4.2 简单的继承
1.4.3 利用虚函数继承
1.5 软件工程中的继承
1.6 编写泛型代码
1.6.1 泛型的实例
1.6.2 约束
1.6.3 一些思考
1.7 组合
1.8 异步代码
1.9 最后的思考
第2章 日志、错误与测试驱动开发
2.1 日志管理
2.1.1 简单的log4net例子
2.1.2 利用ilog接口生成消息
1.1 理解类型
1.2 模块化与可重用代码
1.3 利用作用域控制访问
1.4 理解继承
1.4.1 class与struct在继承上的区别
1.4.2 简单的继承
1.4.3 利用虚函数继承
1.5 软件工程中的继承
1.6 编写泛型代码
1.6.1 泛型的实例
1.6.2 约束
1.6.3 一些思考
1.7 组合
1.8 异步代码
1.9 最后的思考
第2章 日志、错误与测试驱动开发
2.1 日志管理
2.1.1 简单的log4net例子
2.1.2 利用ilog接口生成消息
译者序回到顶部↑
初看书名中的Foundation，会让人觉得这不过又是一本讲解面向对象以及设计模式基础知识的图书。市面上流行的模式方面的书籍还不够多吗？.
说实话，刚从图灵公司编辑处获得此书时，我的感觉也是这样，甚至有一点点不屑。但随着深入地翻译，我越发感觉这样的书名对于这样的内容也许根本就是不合适的。未曾阅读章节内容，仅从目录即可一瞥作者的别具匠心：作者是在从宏观的角度引导如何构建健壮而具有可维护性和可扩展性的应用程序。
从程序的根基，到架构，到脉络（实现算法），到代码合理性，到数据持久化，到对模式的重构，作者以设计模式为主线穿插其中，深入浅出，融会贯通，为读者展现了一条清晰易懂的构建之路。..
虽然书中的程序代码是以C#编写的，但是简洁易懂，对于稍具OOP经验的开发者来说完全不足以成为阅读的障碍，毕竟，书中的精髓在于思想而不是代码的堆砌。在领悟了作者的构建之道后，聪明的开发者一定能够举一反三。
我的同事李彦娜、张广亮也参与了本书的翻译工作，在此对他们表示由衷的感谢。牺牲了那么多私人生活时间，个中的辛苦只有他们自己了解。同时感谢他们能够容忍我一遍一遍的催促和埋怨。
感谢所有热心的读者，希望本书能在你通往技术殿堂的道路上提供许多的帮助。翻译中有不尽如人意的地方在所难免，期待读者的批评指正。
感谢傅志红编辑和人民邮电出版社给予我们这样的机会，在翻译的同时我们又学到了很多东西。
最后，感谢所有为此书的翻译、制作、出版、发行做出贡献的人们。...
译者
2006年8月
说实话，刚从图灵公司编辑处获得此书时，我的感觉也是这样，甚至有一点点不屑。但随着深入地翻译，我越发感觉这样的书名对于这样的内容也许根本就是不合适的。未曾阅读章节内容，仅从目录即可一瞥作者的别具匠心：作者是在从宏观的角度引导如何构建健壮而具有可维护性和可扩展性的应用程序。
从程序的根基，到架构，到脉络（实现算法），到代码合理性，到数据持久化，到对模式的重构，作者以设计模式为主线穿插其中，深入浅出，融会贯通，为读者展现了一条清晰易懂的构建之路。..
虽然书中的程序代码是以C#编写的，但是简洁易懂，对于稍具OOP经验的开发者来说完全不足以成为阅读的障碍，毕竟，书中的精髓在于思想而不是代码的堆砌。在领悟了作者的构建之道后，聪明的开发者一定能够举一反三。
我的同事李彦娜、张广亮也参与了本书的翻译工作，在此对他们表示由衷的感谢。牺牲了那么多私人生活时间，个中的辛苦只有他们自己了解。同时感谢他们能够容忍我一遍一遍的催促和埋怨。
感谢所有热心的读者，希望本书能在你通往技术殿堂的道路上提供许多的帮助。翻译中有不尽如人意的地方在所难免，期待读者的批评指正。
感谢傅志红编辑和人民邮电出版社给予我们这样的机会，在翻译的同时我们又学到了很多东西。
最后，感谢所有为此书的翻译、制作、出版、发行做出贡献的人们。...
译者
2006年8月
前言回到顶部↑
模式是一个已经被前人充分讨论过的有趣话题。最早谈及模式的书是Erich Gamma等编写的《设计模式》(Boston:Addison-Wesley,1995)。该书出版时，模式还是一种新的思想和概念；而现在该书已经成为设计模式的必备参考书，其中阐述的设计模式成为了各种应用程序的基础。.
本书阐述了应用于.NET 2.0框架的设计模式。其中的一些设计模式来自于该书，一些则来自其他来源。本书的重点并不是要定义各种模式，而是用一种编程语言（例如C#）来演示各种模式的应用。因为最初的设计模式是利用C++进行阐述的，与.NET以及C#之间存在着很大的语言差异。
为什么使用模式
你也许会问：“为什么要写这本书，为什么要使用模式？”的确很奇怪，这个想法是在我培训学生如何使用设计模式的时候冒出来的。当时学生们正在做练习，我看见一位学生编写代码时使用一个类而不是接口作为基类。我问他为什么这样编写代码，他的回答是：“因为我一直都是这样做的。”这位同学的方法是错误的，但是他的回答揭示了一个很有趣的观点：当一个基类足够好的时候为什么还要使用接口呢？就在那时，我突然想到：先教授模式再教授面向对象编程（OOP），理解就会更为容易。
当学习传统的OOP技术时，老师会讲到有关形状、矩形以及其他的抽象主题。你会学到一个类如何负责它自己的数据以及如何实现这些责任。这种学习方式的问题是，它解释了面向对象编程，但是并没有解释如何利用具体的方案来解决问题。例如，如何实例化一个类型，将它的引用传递给另一个类，并将信息持久化到媒介中？传统面向对象编程的问题是，在实现解决方案时只给出了模糊的指导。
模式就不同了，它给出了一个预定义的形式，告诉你在什么时候该做什么。考虑下面的情况：学习如何烘焙蛋糕。你知道，蛋糕是由面粉、鸡蛋、牛奶、发酵粉以及一些其他原料做成的，但并不是所有蛋糕都是一样的。如果加入过多的发酵粉，蛋糕会过分地发酵胀起；如果加入过多的鸡蛋，蛋糕吃起来会像是煎蛋卷。面向对象编程就像是烘焙蛋糕一样，你知道所需的原料，也知道这些原料的作用，但是不知道这些原料的比例以及制作蛋糕的步骤。就像好的食谱能够帮助你把这些原料变成美味的蛋糕一样，模式能够帮助你将代码转换成高效的程序。
在不知道原料的作用以及它们之间是如何相互作用的情况下，也可能只根据食谱制作出蛋糕。但这种方法的问题是它无法奏效。例如，假设你正在准备一顿饭，开始是豌豆汤，主菜是胡椒薄荷沙司调味的鲑鱼、南瓜以及黄豆面条，最后是餐后甜点冰淇淋。尽管可能每道菜的味道都很好，但这个菜谱听起来并不令人胃口大开。其中的问题是模式，就像是菜谱，之间是相互作用和配合的，因此需要协调。协调模式的前提就是对面向对象编程技术有一个基本的理解。
什么是模式
模式就像菜谱，只不过用于创建模式的原料是面向对象的原理。例如，考虑下面的源代码：
类Derived实现了接口IBaseInterface，这就是典型的Bridge模式的实现。一定会有人问，为什么使用接口而不是类呢？从面向对象的角度看，它们的结果很相似。这就引发了一个问题，为什么在编程语言中要用接口呢？答案是：因为模式定义了最佳实践，而该实践已经被证明在应用程序开发中是有益的。从大量的编程经验来看，在使用基类型以及实现Bridge模式时，接口比类更有用。
模式不同于最佳实践，就像理论不同于猜想一样。理论基于已经被科学方法无数次证明的想法，科学方法是一种其他人也能够重新生成结果的实验方法。模式就像是一本食谱，它定义了一系列的步骤以及原料，当按照定义的步骤操作原料时，就能够做出相同的蛋糕。猜想是一种想法，它很可能是正确的，但是并没有被不同的人用必要的重复的实验证明。猜想是理论的先驱，意味着最佳实践是模式的先驱。..
《设计模式》一书中定义的模式已经被证明是有效的，并且已经应用于多种情况。例如，利用Factory模式定义的结构，可以在不同的编程环境中，利用不同的编程语言产生相同的结果。
你能从本书获得什么
除了模式以及面向对象原理，通过本书将学习像音乐家阅读乐谱那样阅读代码。思考一下，音乐家利用只有音乐家才懂的符号来表达他们的思想。乐谱，代表了要演奏的音乐，对于不懂的人来说就像是一堆胡乱画出的符号。然而对于音乐家，它是巴赫、莫扎特、AC/DC乐队或者说唱乐手Eminem，意味深长。当阅读乐谱时，音乐家知道何时演奏他们的乐器，以及当时产生的是一种什么样的情绪。没有对乐谱的简化和抽象，音乐家阅读乐谱后只知道那是一段怎样的音乐。
本书的目的就是使你能够阅读一段代码并且明白其中的意图。在很多开源项目中，经常需要阅读其他人编写的代码。对于其他类型的项目情况就不是这样，每位编程者都使用自己喜欢的风格和技术编写代码。例如，就像是将大括号放在哪里这样的小问题也会引发激烈的争论。会有这种争论的原因是，每位编程者都在实践中或者参加会议的幻灯片中或者别人的注释中学到了一些风格和技术。阅读一段代码并不只是识别出一些关键字，而是理解在一种环境中使用一段关键字解决一个特定的问题。简言之，阅读一段代码就是在模式的环境中诠释OOP。
从哲学的层面考虑一下，一种编程语言为什么会存在？问问自己，为什么一种编程语言包含了一个特定的关键字、概念或者策略？答案是，因为那个关键字、概念或者策略在一个特定的环境中解决了一个特定的问题。但并没有解释何时才是使用这种特征的最佳时机。例如，在C#中，可以使用关键字struct、class、interface、abstract以及sealed来定义一个用于程序的类型。通常编程者知道上述关键字的技术理由以及效果。然而，编程者通常不知道每个关键字在什么情况下应该或者不应该使用。这就回到了起点，不管在什么地方使用，编程者会依赖于他们自己的习惯或风格。这并不是正确的编程方法，因为它有可能依赖于试错（trial and error）。
本书内容
本书的每一章在知识上都是循序渐进的，并且各有明确的目标。
第1章揭示了面向对象编程的本质，利用C#定义和阐述了模块化和异常等概念。阅读这一章有助于更容易地理解各种OOP词汇。
第2章的主要目的是定义和阐述测试驱动开发，它是一种通过一致地创建测试和源代码来开发软件的方法。这种方法的优点是保持源代码的稳定和一致。
本书阐述了应用于.NET 2.0框架的设计模式。其中的一些设计模式来自于该书，一些则来自其他来源。本书的重点并不是要定义各种模式，而是用一种编程语言（例如C#）来演示各种模式的应用。因为最初的设计模式是利用C++进行阐述的，与.NET以及C#之间存在着很大的语言差异。
为什么使用模式
你也许会问：“为什么要写这本书，为什么要使用模式？”的确很奇怪，这个想法是在我培训学生如何使用设计模式的时候冒出来的。当时学生们正在做练习，我看见一位学生编写代码时使用一个类而不是接口作为基类。我问他为什么这样编写代码，他的回答是：“因为我一直都是这样做的。”这位同学的方法是错误的，但是他的回答揭示了一个很有趣的观点：当一个基类足够好的时候为什么还要使用接口呢？就在那时，我突然想到：先教授模式再教授面向对象编程（OOP），理解就会更为容易。
当学习传统的OOP技术时，老师会讲到有关形状、矩形以及其他的抽象主题。你会学到一个类如何负责它自己的数据以及如何实现这些责任。这种学习方式的问题是，它解释了面向对象编程，但是并没有解释如何利用具体的方案来解决问题。例如，如何实例化一个类型，将它的引用传递给另一个类，并将信息持久化到媒介中？传统面向对象编程的问题是，在实现解决方案时只给出了模糊的指导。
模式就不同了，它给出了一个预定义的形式，告诉你在什么时候该做什么。考虑下面的情况：学习如何烘焙蛋糕。你知道，蛋糕是由面粉、鸡蛋、牛奶、发酵粉以及一些其他原料做成的，但并不是所有蛋糕都是一样的。如果加入过多的发酵粉，蛋糕会过分地发酵胀起；如果加入过多的鸡蛋，蛋糕吃起来会像是煎蛋卷。面向对象编程就像是烘焙蛋糕一样，你知道所需的原料，也知道这些原料的作用，但是不知道这些原料的比例以及制作蛋糕的步骤。就像好的食谱能够帮助你把这些原料变成美味的蛋糕一样，模式能够帮助你将代码转换成高效的程序。
在不知道原料的作用以及它们之间是如何相互作用的情况下，也可能只根据食谱制作出蛋糕。但这种方法的问题是它无法奏效。例如，假设你正在准备一顿饭，开始是豌豆汤，主菜是胡椒薄荷沙司调味的鲑鱼、南瓜以及黄豆面条，最后是餐后甜点冰淇淋。尽管可能每道菜的味道都很好，但这个菜谱听起来并不令人胃口大开。其中的问题是模式，就像是菜谱，之间是相互作用和配合的，因此需要协调。协调模式的前提就是对面向对象编程技术有一个基本的理解。
什么是模式
模式就像菜谱，只不过用于创建模式的原料是面向对象的原理。例如，考虑下面的源代码：
类Derived实现了接口IBaseInterface，这就是典型的Bridge模式的实现。一定会有人问，为什么使用接口而不是类呢？从面向对象的角度看，它们的结果很相似。这就引发了一个问题，为什么在编程语言中要用接口呢？答案是：因为模式定义了最佳实践，而该实践已经被证明在应用程序开发中是有益的。从大量的编程经验来看，在使用基类型以及实现Bridge模式时，接口比类更有用。
模式不同于最佳实践，就像理论不同于猜想一样。理论基于已经被科学方法无数次证明的想法，科学方法是一种其他人也能够重新生成结果的实验方法。模式就像是一本食谱，它定义了一系列的步骤以及原料，当按照定义的步骤操作原料时，就能够做出相同的蛋糕。猜想是一种想法，它很可能是正确的，但是并没有被不同的人用必要的重复的实验证明。猜想是理论的先驱，意味着最佳实践是模式的先驱。..
《设计模式》一书中定义的模式已经被证明是有效的，并且已经应用于多种情况。例如，利用Factory模式定义的结构，可以在不同的编程环境中，利用不同的编程语言产生相同的结果。
你能从本书获得什么
除了模式以及面向对象原理，通过本书将学习像音乐家阅读乐谱那样阅读代码。思考一下，音乐家利用只有音乐家才懂的符号来表达他们的思想。乐谱，代表了要演奏的音乐，对于不懂的人来说就像是一堆胡乱画出的符号。然而对于音乐家，它是巴赫、莫扎特、AC/DC乐队或者说唱乐手Eminem，意味深长。当阅读乐谱时，音乐家知道何时演奏他们的乐器，以及当时产生的是一种什么样的情绪。没有对乐谱的简化和抽象，音乐家阅读乐谱后只知道那是一段怎样的音乐。
本书的目的就是使你能够阅读一段代码并且明白其中的意图。在很多开源项目中，经常需要阅读其他人编写的代码。对于其他类型的项目情况就不是这样，每位编程者都使用自己喜欢的风格和技术编写代码。例如，就像是将大括号放在哪里这样的小问题也会引发激烈的争论。会有这种争论的原因是，每位编程者都在实践中或者参加会议的幻灯片中或者别人的注释中学到了一些风格和技术。阅读一段代码并不只是识别出一些关键字，而是理解在一种环境中使用一段关键字解决一个特定的问题。简言之，阅读一段代码就是在模式的环境中诠释OOP。
从哲学的层面考虑一下，一种编程语言为什么会存在？问问自己，为什么一种编程语言包含了一个特定的关键字、概念或者策略？答案是，因为那个关键字、概念或者策略在一个特定的环境中解决了一个特定的问题。但并没有解释何时才是使用这种特征的最佳时机。例如，在C#中，可以使用关键字struct、class、interface、abstract以及sealed来定义一个用于程序的类型。通常编程者知道上述关键字的技术理由以及效果。然而，编程者通常不知道每个关键字在什么情况下应该或者不应该使用。这就回到了起点，不管在什么地方使用，编程者会依赖于他们自己的习惯或风格。这并不是正确的编程方法，因为它有可能依赖于试错（trial and error）。
本书内容
本书的每一章在知识上都是循序渐进的，并且各有明确的目标。
第1章揭示了面向对象编程的本质，利用C#定义和阐述了模块化和异常等概念。阅读这一章有助于更容易地理解各种OOP词汇。
第2章的主要目的是定义和阐述测试驱动开发，它是一种通过一致地创建测试和源代码来开发软件的方法。这种方法的优点是保持源代码的稳定和一致。
相关资源回到顶部↑
· 【推荐】众多高校学子口口相传，他们共同的选择--华清远见嵌入式学院(嵌入式Linux就业课程、3G手机开发就业课程，通过入学测试即签100%就业协议，4个月集中实训，世界500强企业成功就业保障！！！)· 【亚嵌教育 嵌入式培训专家】(嵌入式培训，嵌入式Linux培训，ARM培训,Linux培训，3G培训，Android培训，WINCE培训，DSP培训，FPGA培训，嵌入式就业培训)
· InfoQ中文站论坛：.NET讨论区(InfoQ .NET)
· 程序员的7种武器(正则表达式、编程语言、数据库、算法、软件调试、开发环境)
· WCF的开山之作 WCF画卷的清明上河图(WCF WF WPF)
· 图灵公司详细书目
评论交流
共有20人开贴评论 48人参与评论 15人参与打分 查看
评价等级：
发表于：2007-12-18 23:52:00
今天刚开始翻阅这本书，通常我都是在看完全书以后才会发表评论，不过因为没看多少页就发现了一些明显的错误，因而就上来看一下有否评论，没想到这里的讨论早已炸开了锅。哈哈，我就也凑热闹说上几句：
首先，我相信绝大部分的IT书籍的译者主要都是IT技术人员而非外语专业人员出身的，因此对于一些无关痛痒的内容（尤其是一些美式幽默或用典），如果翻译出来略有偏差也无可厚非。比如象下面的例子：
第6页倒数第10行“对于快速引用来说”（For quick reference）改为“简而言之”比较容易明白。
第11页第7行“细心的读者可能会说我的例子似乎偏离了正轨”（The observant reader will say that my example is biased），细心如我者也没有发现作者跑题了，实质上这里作者的意思是说对于值类型的讨论所举的例子都是将值类型作为参数传给一个方法，而没有演示其他情况的例子。因此改为“有失偏颇”或者“不够全面”比较符合原文的意思。
第13页倒数第2行“不受时间限制”（time proof）译为“经得起时间的考验”比较容易理解。
但是，从另一角度来看，因为译者是IT技术人员，因此对于一些近乎常识性的技术性内容如果出现错误的话就比较难接受了。例如：
第6页倒数第15以及11行的“父类”（subclassed type）均应改为“子类”。
还有其他读者已经提到的22页的Port。
我一向认为书必读懂而后能译，因此出现这样的低级错误就难免让人对译者以及译著的信心产生动摇。
最后还有一个问题就是书的索引问题，我之前购买了同样是图灵出品的《Effective C#中文版》采用的是“页页对译，保留索引”的做法。窃以为，这是所有优秀译作所必需具备的一个基本条件，但是这本书连这个基本条件都无法达到。相信出版商所谓的“模式不仅超越了GoF”云云纯属哗众取宠，否则断不至于如此厚彼薄此。希望图灵不要只顾着蝇头小利，要努力向博文姐姐学习，认真做好每一本书。
首先，我相信绝大部分的IT书籍的译者主要都是IT技术人员而非外语专业人员出身的，因此对于一些无关痛痒的内容（尤其是一些美式幽默或用典），如果翻译出来略有偏差也无可厚非。比如象下面的例子：
第6页倒数第10行“对于快速引用来说”（For quick reference）改为“简而言之”比较容易明白。
第11页第7行“细心的读者可能会说我的例子似乎偏离了正轨”（The observant reader will say that my example is biased），细心如我者也没有发现作者跑题了，实质上这里作者的意思是说对于值类型的讨论所举的例子都是将值类型作为参数传给一个方法，而没有演示其他情况的例子。因此改为“有失偏颇”或者“不够全面”比较符合原文的意思。
第13页倒数第2行“不受时间限制”（time proof）译为“经得起时间的考验”比较容易理解。
但是，从另一角度来看，因为译者是IT技术人员，因此对于一些近乎常识性的技术性内容如果出现错误的话就比较难接受了。例如：
第6页倒数第15以及11行的“父类”（subclassed type）均应改为“子类”。
还有其他读者已经提到的22页的Port。
我一向认为书必读懂而后能译，因此出现这样的低级错误就难免让人对译者以及译著的信心产生动摇。
最后还有一个问题就是书的索引问题，我之前购买了同样是图灵出品的《Effective C#中文版》采用的是“页页对译，保留索引”的做法。窃以为，这是所有优秀译作所必需具备的一个基本条件，但是这本书连这个基本条件都无法达到。相信出版商所谓的“模式不仅超越了GoF”云云纯属哗众取宠，否则断不至于如此厚彼薄此。希望图灵不要只顾着蝇头小利，要努力向博文姐姐学习，认真做好每一本书。
)
加载中...| 我要写评论 |
| 查看所有评论交流(共20条) |
