Microsoft.NET企业级应用架构设计
点击看大图基本信息
- 作者： (美)Dino Esposito Andrea Saltarello
- 译者： 陈黎夫
- 出版社：人民邮电出版社
- ISBN：9787115227126
- 上架时间：2010-6-11
- 出版日期：2010 年6月
- 开本：16开
- 页码：412
- 版次：1-1
- 所属分类：
计算机 > 软件与程序设计 > .NET > 综合
内容简介回到顶部↑
作译者回到顶部↑
目录回到顶部↑
第一部分 设计原则
第1章 当代的架构师和架构 3
1.1 软件架构到底是什么 4
1.1.1 将架构原则应用至软件中 4
1.1.2 什么属于架构，什么不属于 7
1.1.3 架构与决定相关 9
1.1.4 软件的需求和质量 11
1.2 架构师到底是什么 15
1.2.1 架构师的职责 15
1.2.2 你知道有多少种架构师吗 17
1.2.3 对架构师的一些常见误解 18
1.3 软件开发流程概览 21
1.3.1 软件生命周期 21
1.3.2 软件开发模型 23
1.4 小结 26
1.5 本章的墨菲法则 27
第2章 uml必要知识 28
2.1 uml概览 29
2.1.1 建模语言的出现动机和历史 30
2.1.2 uml的模式和使用方法 33
第1章 当代的架构师和架构 3
1.1 软件架构到底是什么 4
1.1.1 将架构原则应用至软件中 4
1.1.2 什么属于架构，什么不属于 7
1.1.3 架构与决定相关 9
1.1.4 软件的需求和质量 11
1.2 架构师到底是什么 15
1.2.1 架构师的职责 15
1.2.2 你知道有多少种架构师吗 17
1.2.3 对架构师的一些常见误解 18
1.3 软件开发流程概览 21
1.3.1 软件生命周期 21
1.3.2 软件开发模型 23
1.4 小结 26
1.5 本章的墨菲法则 27
第2章 uml必要知识 28
2.1 uml概览 29
2.1.1 建模语言的出现动机和历史 30
2.1.2 uml的模式和使用方法 33
前言回到顶部↑
正确的判断来自于经验，而经验则来自于错误的判断。
——Fred Brooks(1)
每次遇到软件项目时，我们都会创建一个解决方案。这个过程就叫做架构设计，而架构设计的最终产物就是软件架构。软件架构可以分为隐式和显式两种。
隐式架构是指那些在我们头脑中描绘出的设计，往往写在Microsoft Office Word文档或记事本上。隐式架构可以看做是一系列原有经验，其他类似项目中学到的技巧以及将抽象的概念进行组织并应用到手头项目中的能力。例如，若你是个专业的木匠，那么显然不需要为了给宠物狗造窝而大动干戈地绘图或精确测量，只要几分钟你就能想出一个隐式的架构。随后便可直奔主题开始工作，仅仅在必要的时候进行合适的判断即可。这样在项目结束时，结果也会很不错。
若项目干系人的想法过于复杂精细，以至于无法用经验和头脑中的想法来处理，则需要采用显式架构。这时，你就需要做一些有预见性的规划并获取一定的指导，然后应用合理的模式和实践，以期实现最终的目标。
架构是什么
“架构”这个词已被用在很多不同的上下文中。其定义可以在《牛津英语词典》或软件领域中的美国国家标准学会(American National Standards Institute，ANSI)／电气和电子工程师学会(Institute Of Electrical and Electronics Engineers，IEEE)的标准库中找到。在ANSI和IEEE的释义中，架构的定义主要包括规划、设计以及创建软件的过程。软件架构是指那些用来为项目干系人提供足够说明(如某个用户需求)的一些人工产物。
架构不能脱离其上下文而存在。在设计软件系统之前，你需要理解系统是如何与外部环境发生关系以及如何嵌入到外部环境中的。作为软件架构师，自然不能忽略当前环境中使用的开发技术——对于本书来说则是．NET平台。
回到主题，到底什么是架构?
我们可以将架构理解为一种正确创造那些基本确定的决策的艺术。架构是一个系统中最为核心的部分，是构造系统过程中的支柱。而架构师则负责架构的设计，其工作包含多个方面，例如，捕获需求、设计系统、确保实现、满足要求，并从总体上保证用户得到所需要的软件——不过最终的软件并不一定是像用户一开始想象的那样。
软件架构有一些预先的条件，即设计原则，还有一个后续条件，即最终系统必须能够得到期待的结果。相应地，本书也这样划分为两大部分：设计原则和系统设计。
本书的第一部分关注于架构师的职责：架构师的工作、架构师与谁沟通、架构师给谁汇报等。架构师主要负责捕获需求、设计系统并将设计交付给开发团队。有关设计的沟通工具一般基于UML(Unified Modeling Language)草图，有时也使用UML设计图。架构师首先应用软件工程中的一些通用原则，随后再使用面向对象设计中的原则，以便将系统拆分成越来越小的模块，从而判断出哪些属于架构(基本不会改变的部分)，哪些不属于架构。面向对象设计的一个主要目的就是让代码易于维护和扩展，并易于阅读和理解。架构师还需要认同并保证可维护性、安全性以及可测试性在开始构造系统时就考虑周全。
本书的第二部分则主要描述企业级系统一般的分层，包括表现层、业务层和数据访问层。这一部分介绍了各个层中常用到的设计模式，包括DomainModel、Model-View-Presenter和Service Layer等，还介绍了技术的演化趋势，并总结了当代软件项目中逐渐出现的一些新工具，例如，O／R映射工具和依赖注入容器等。
那么说到底，本书讲的是什么呢?
本书介绍的内容是为了帮助你在．NET平台下尽可能完美地满足客户的需求。本书中给出的模式、原则和技术均针对一般情况，而不是某个特定领域中的应用程序。好的软件架构师能够非常有效地控制项目的复杂性。只有良好地控制了复杂性并保持高可维护性，我们才能对抗那条无懈可击的莫菲法则——没有什么东西可以如期或按预算完成。
所谓专家，是指那些可以有效处理复杂性的人，而不是简单地估计哪个工作耗时最长、花费最多，这是对另一条流行的莫菲法则的改写。
面向读者
前面经常提到“架构师”，那么本书面向的读者一定要是软件架构师吗?当然，架构师和高级开发人员自然是本书的主要受众，不过开发任何一种．NET应用程序的开发者都能从本书中受益。每个希望成为架构师的人都会觉得本书物有所值。
那么阅读本书的预先条件是什么呢?
扎实的面向对象编程技术、对．NET平台和数据访问技术有足够的了解都是阅读本书的必备条件。本书给出了很多设计模式，不过介绍的语言都力图易于理解，并不拘泥于形式。此外，我们还竭力保证了本书的可读性。这并不是一本抽象的有关设计概念的图书，也不是传统的架构图书——反复地包含很多交叉引用，大量方括号中难懂的字符串，链接到书后参考资料中多如牛毛的老论文等。
——Fred Brooks(1)
每次遇到软件项目时，我们都会创建一个解决方案。这个过程就叫做架构设计，而架构设计的最终产物就是软件架构。软件架构可以分为隐式和显式两种。
隐式架构是指那些在我们头脑中描绘出的设计，往往写在Microsoft Office Word文档或记事本上。隐式架构可以看做是一系列原有经验，其他类似项目中学到的技巧以及将抽象的概念进行组织并应用到手头项目中的能力。例如，若你是个专业的木匠，那么显然不需要为了给宠物狗造窝而大动干戈地绘图或精确测量，只要几分钟你就能想出一个隐式的架构。随后便可直奔主题开始工作，仅仅在必要的时候进行合适的判断即可。这样在项目结束时，结果也会很不错。
若项目干系人的想法过于复杂精细，以至于无法用经验和头脑中的想法来处理，则需要采用显式架构。这时，你就需要做一些有预见性的规划并获取一定的指导，然后应用合理的模式和实践，以期实现最终的目标。
架构是什么
“架构”这个词已被用在很多不同的上下文中。其定义可以在《牛津英语词典》或软件领域中的美国国家标准学会(American National Standards Institute，ANSI)／电气和电子工程师学会(Institute Of Electrical and Electronics Engineers，IEEE)的标准库中找到。在ANSI和IEEE的释义中，架构的定义主要包括规划、设计以及创建软件的过程。软件架构是指那些用来为项目干系人提供足够说明(如某个用户需求)的一些人工产物。
架构不能脱离其上下文而存在。在设计软件系统之前，你需要理解系统是如何与外部环境发生关系以及如何嵌入到外部环境中的。作为软件架构师，自然不能忽略当前环境中使用的开发技术——对于本书来说则是．NET平台。
回到主题，到底什么是架构?
我们可以将架构理解为一种正确创造那些基本确定的决策的艺术。架构是一个系统中最为核心的部分，是构造系统过程中的支柱。而架构师则负责架构的设计，其工作包含多个方面，例如，捕获需求、设计系统、确保实现、满足要求，并从总体上保证用户得到所需要的软件——不过最终的软件并不一定是像用户一开始想象的那样。
软件架构有一些预先的条件，即设计原则，还有一个后续条件，即最终系统必须能够得到期待的结果。相应地，本书也这样划分为两大部分：设计原则和系统设计。
本书的第一部分关注于架构师的职责：架构师的工作、架构师与谁沟通、架构师给谁汇报等。架构师主要负责捕获需求、设计系统并将设计交付给开发团队。有关设计的沟通工具一般基于UML(Unified Modeling Language)草图，有时也使用UML设计图。架构师首先应用软件工程中的一些通用原则，随后再使用面向对象设计中的原则，以便将系统拆分成越来越小的模块，从而判断出哪些属于架构(基本不会改变的部分)，哪些不属于架构。面向对象设计的一个主要目的就是让代码易于维护和扩展，并易于阅读和理解。架构师还需要认同并保证可维护性、安全性以及可测试性在开始构造系统时就考虑周全。
本书的第二部分则主要描述企业级系统一般的分层，包括表现层、业务层和数据访问层。这一部分介绍了各个层中常用到的设计模式，包括DomainModel、Model-View-Presenter和Service Layer等，还介绍了技术的演化趋势，并总结了当代软件项目中逐渐出现的一些新工具，例如，O／R映射工具和依赖注入容器等。
那么说到底，本书讲的是什么呢?
本书介绍的内容是为了帮助你在．NET平台下尽可能完美地满足客户的需求。本书中给出的模式、原则和技术均针对一般情况，而不是某个特定领域中的应用程序。好的软件架构师能够非常有效地控制项目的复杂性。只有良好地控制了复杂性并保持高可维护性，我们才能对抗那条无懈可击的莫菲法则——没有什么东西可以如期或按预算完成。
所谓专家，是指那些可以有效处理复杂性的人，而不是简单地估计哪个工作耗时最长、花费最多，这是对另一条流行的莫菲法则的改写。
面向读者
前面经常提到“架构师”，那么本书面向的读者一定要是软件架构师吗?当然，架构师和高级开发人员自然是本书的主要受众，不过开发任何一种．NET应用程序的开发者都能从本书中受益。每个希望成为架构师的人都会觉得本书物有所值。
那么阅读本书的预先条件是什么呢?
扎实的面向对象编程技术、对．NET平台和数据访问技术有足够的了解都是阅读本书的必备条件。本书给出了很多设计模式，不过介绍的语言都力图易于理解，并不拘泥于形式。此外，我们还竭力保证了本书的可读性。这并不是一本抽象的有关设计概念的图书，也不是传统的架构图书——反复地包含很多交叉引用，大量方括号中难懂的字符串，链接到书后参考资料中多如牛毛的老论文等。
【插图】
加载中...
