第一部分 综述
第1章 本书会讨论什么内容
从软件工程说起。提起这个概念，往往令人想起CMM、RUP、印度模式等。管理的因素，在软件开发过程中起着非常重要的作用，然而，软件工程并非只指软件开发的管理工作，而是一个范围很广的综合性学科。在软件工程中，大约一半的内容是专业性很强的，涉及到软件分析、设计甚至编码的技术。所谓的结构化、面向对象，都在软件工程的范畴内。“软件工程范围极为广泛。软件工程的某些方面属于数学或计算机科学，其他方面可归入经济学、管理学或心理学中。”
软件业一直在探讨，如何使软件实现如同传统产业一样的大规模生产。软件工程的提出，便是为了实现这个愿望。然而，虽然软件工程至今已经有了很大的发展，软件的大规模工业化生产仍然没有实现。原因何在？
从软件的本质属性来说，软件的复杂性是软件的本质属性，在这个属性没有改变之前，软件便不会实现同传统产业一样的工厂化生产。
从软件生产的介质来说，传统产业生产都是有形的物质产品，人的生产活动都受制于生产资料这些物质介质；然而，软件生产的介质，却是无形的人类的思维。物质资料的生产，受制于物质本身的属性，不容易为人类的思维所左右，并且容易被大量复制，这使得工业化大生成为可能。而人类的思维，却是如此的容易变化，更关键的是不能被复制，甚至同一个人，不同时期思维的复制都不可能，这使得软件这个纯粹依赖人的思维活动的生产实现大规模工业化生产是如此的困难。实际上，不仅仅是软件产业，凡是主要生产介质是人本身的活动的产业，都很难实现工业化生产，如咨询、演艺等。
从生产过程来看，对于传统产业来说，产品的设计和生产是分开的。在设计阶段，主要的工作是人的思维，因此，在这个阶段，同软件一样，不是批量生产的。而在生产阶段，主要的对象便是物质资料，并且一切标准已经制定，只需要在流水线上大量复制。对于传统产业来说，设计和生产的界限是如此的明确，并且，生产和设计的比重是如此的悬殊。然而，对于软件产业来说，软件的生产过程便是设计的过程，纯粹的生产过程几乎不存在（或许，光盘的复制算是），这使得软件的生产形态同传统产业必然存在区别。
对于软件的开发过程来说，从业务模型、需求分析、系统架构、系统分析和设计、到最后代码实现，越往前，抽象层次越高，可控性越小，越往后，越接近实际，可控性越大，因此，在软件开发中，核心团队的作用是如此巨大，一个软件产品的成败，核心团队的核心人员的作用在很大程度上是决定性的。对于软件开发来说，如果软件开发要实现工业化生产，必定是从后向前推进，从编码开始。印度模式或许给出了这么一个例子。
因此，我们在软件工程的路上，只是在不断的向工程化的目标迈进，但是，要达到这个目标，可能会花很长的时间。技术上的每一次进步，都使我们向这个目标迈进了一步。在软件工程的发展过程中，技术进步起了非常大，甚至可以说是决定性的作用。随着采用的技术的不同，所采用的管理方法也在不断变化。软件工程技术的很多方面，也是为管理做准备的。优秀的软件开发技术的采用，能够弥补我们在工程化方面的不足，从而使得软件开发更加可控，软件质量更加有保障。
本书不准备讨论软件工程过程的问题，而只是对软件工程中软件技术的一个方面——系统框架设计，做一些探讨。
现在，很多开发人员都已经意识到这很重要的一点，那就是，在开发一个应用软件系统的时候，一个好的系统框架是非常重要的。从底层开始构建应用程序，是一件吃力不讨好的事情，而没有框架的应用程序，则很难想象会是一个好的应用程序。
除了对于开发的直接帮助，一个好的框架对于公司的知识管理也是非常有意义的。想象一下，我们经常在讨论，现在是一个知识经济的时代，尤其对于软件公司来说，知识（拥有这些知识的员工）就是公司最大的财富。那么，怎么来进行有效的知识管理呢？
首先，应当明确，知识管理，一个重要的目的，就是要把员工对公司最重要的知识沉淀下来。公司的每个员工头脑里都有很多的知识，这些知识对于员工来说是很重要的，但是其重要性同公司并不是完全一致的。某些知识，对于某个员工来说是最重要的，但是对于公司可能并不需要。知识管理需要做的，是把员工对公司最重要的知识累积起来。
其次，知识管理必须有一个载体。如果知识管理没有载体，那么，公司的知识就存在于员工的头脑之中，一旦这个员工离职，那么，知识也就离去了，没有办法沉淀。如果只是把公司做过的项目的文档作为载体，那么，这个载体就过于零碎了。实际上，如果公司有一个统一的框架，那么，这个框架就是一个很好的知识管理的载体。因为，这个框架，必定是集中了公司所有软件项目的共同点的，集中了对于公司最重要的知识的精华，能够为公司所有的项目服务。另外，随着框架的不断被使用，框架本身也会随之升级优化。对于一个新成员的加入，他只要理解掌握了这个框架，就可以很好的融入团队中来；而人员的离去，也已经把自己对公司最重要的知识留在了这个框架中。可以说，在这里，框架承担了一个知识管理平台的作用。一个最好的例子就是微软的Windows。这是微软所有知识的最集中的平台。
软件，从本质上来说，就是现实世界在计算机中的模拟。在考虑应用软件系统架构的时候，实际上，考虑的问题主要在于：处理什么？怎么处理？如何使用？因此，应用软件系统，需要关注的方面，概括起来，主要包括以下三个大类：
1、 处理的对象，也就是数据。
2、 处理的方式，也就是我们的系统如何来处理系统的逻辑。
3、 如何进行交互，这个交互包括用户（使用者），以及外部系统。
在应用软件系统中，数据是处理的基本对象，程序总是以一定的数据结构来表现数据，并且，在使用面向对象语言开发的系统中，数据总是以类和对象的形式表现出来。另外一方面，数据总是需要存储，对于大部分应用软件系统来说，通常会采用关系型数据库来保存数据。这样，由于数据在程序和数据库中表现格式的不一致，就必然要求在两者之间进行映射。这个映射，在面向对象设计语言和关系型数据库之间，通常称为对象/关系型映射，即O/R Mapping。
目前，在O/R Mapping部分，在Java平台下，已经有多种可以选择的方案，例如J2EE架构中的Entity Bean，轻量级的JDO，以及开源项目的Hibernate等，由于微软的.Net框架推出时间不长，成熟的O/R Mapping框架并不多见。O/R Mapping框架的选择或者设计是构建应用软件系统的最基本的工作。本书将讨论构建O/R Mapping框架的一些基本理论、概念和方法。
系统的业务逻辑处理，是应用软件系统的核心部分，如何合理的构建业务逻辑、如何提供业务逻辑层的服务，以及表现层如何访问业务逻辑提供的功能，也是应用软件系统需要重点关注的问题。在这个方面，业界已经发展了很多可供选择的范式，如契约式设计、SOA架构(面向服务的架构)等。这些方法指明了设计的方向，同时也需要我们在实际开发中加以应用。
在业务逻辑确定后，随后而来的问题就是，如何向客户端来提供业务逻辑服务，或者说，客户端如何访问这些服务。在多层应用软件系统中，客户端和业务逻辑在物理上可能存在于不同的机器上，也可能存在于同一台机器，但至少，在逻辑上，是存在于两个不同部分，这就涉及到一个问题：这两个层之间如何进行通信？还会涉及到远程过程调用的问题。
当然，现在我们已经有多种技术来远程过程调用，包括Webservice、.Net Remoting、Corba、甚至EJB等。如此多的实现技术，带来的很大的灵活性，但同时也带来了问题，其中一个就是，有多少种服务端技术，就得有多少种相应的客户端访问技术。甚至，在某些分布式应用系统中，应用逻辑使用不同的技术开发，存在于不同的机器上，有的存在于客户机本机，有的使用.Net Remoting开发，存在于局域网内，有的使用因特网上的Web Service，有的时候，我们希望相同的业务逻辑能够支持不同的客户端。
在这种情况下，我们需要一个一致的服务访问编程模型，以统合不同的服务访问模式，简化系统的开发和部署。一个统一的远程过程调用框架的前景是如此的诱人，以至于每一种方法都试图一统天下，但出于种种原因，最终都没有一家能够做到，最新的Web Service就力图做到这一点。实际上，每一种方法的出现，最终都会带来一个副作用，那就是，可供选择的多了一点，混乱也就又多了一点。在实际的开发过程中，我们也需要一个统一的访问方式来解决这个问题。本书将讨论一些可用的方案。
为了更加清晰的进行表述，文章会附加一些程序代码。因为在讲到具体的技术的时候，本书会对各种可用的技术进行比较，因此，本书的代码可能会使用不同的语言，通常是Java和C#，不过，在给出代码的时候，一般都会指明所用的语言。在大部分情况下，如果不说明具体的语言，那么就是C#（因为我比较喜欢这门语言）。因为Java和C#的语法是如此的相像，我想，对有经验的程序员来说，这应该不会造成阅读上的麻烦