l5)Network,网络拓扑结构，以及企业对网络的要求层级，数据传输要求等等。

　　在了解了软件架构的这些本本上的东西，那么我们来搭个应用看看。以我碰到的项目为
例，当然一些技术是可通用的，但这个是一个个案，不代表适用您的项目，只求交流。

　　先交待一下，假设：

　　

1． 系统是建立在微软的架构基础上的，Microsoft System Architecture (MSA)

　　

2． 它是一个 B/S 的 N-Tier 架构

　　

3． 同时它是一个企业级应用系统，信息平台

　　在考虑使用

N-Tier 的过程中，由于系统中没有涉及到要使用跨平台的应用，在可预见

的将来也不会有，所以就把

Web Service 拿掉了。Web Service 从 3 年前就开始用，但是

几个问题还是没有解决：
　　

1. Web Service 从接口继承，如果两个或者两个以上的 Web service 同时从相同的

接口继承，由于

Web Service 的自描述性，每个 Web Service 都重新生成接类，就成了

两个不同的类。
　　

2.Web Service 本身不能被继承，同样由自描述性搞的。

　　

3.Web Service 要真正做到跨平台那就需要做到跨语言，从 Java 到 C#的转化时数

据类型转化是相当麻烦的，基本类型之间就有很大问题，如

byte，sbyte(C#)中，当

Java 中根本就没有 sbyte。早在一年半前曾用相异平台做了一个应用系统，为了处理这个
数据类型转化，我曾想去掉

Web Service。

　　

4.Web Service 方法不能重载，这个很恐怖。

　　

5.Web Service 的安全问题。

　　尽管

Web Service 有其种种好处，连现在的网格都开始醉心于它，更不用说 SOA 了，

本身就是以

Web Service 为核心展开的。但是，Web Service 到底能走向哪里？

　 　 在 开 始 架 构 设 计 之 前 ， 需 要 了 解 一 下 架 构 是 什 么 ， 按 照

IEEE 标准 的定 义是 ： 

Architecture 是一个系统的基本组织，它蕴含于系统的组件中、组件之间的相互关系中、组
件 与 环 境 的 相 互 关 系 中 、 以 及 呈 现 于 其 设 计 和 演 进 的 原 则 中 。

  (The  embodied 

fundamental organization of a system in its components, their relationships to 
each other, and to the environment, and the principles guiding its design and 
evolution. [IEEE Std 1471-2000])

　　一句话，架构就是软件产品的骨架，这个骨架把组件、环境纳入其中，使之能有效得发
挥它们的技能。
　　从架构、技术和需求的关系来看。一个软件产品包含了需求和技术，而架构同样是要包
括需求和技术的，只是它没有全包全括这个需求和技术，应该是一些整体性的需求，尤其
是一些非功能性的需求。如果在构建架构的时候，架构设计人员根本不了解企业使用的目标
软件的整体需求，企业使用目标系统的整体环境，那指望架构适用显然有点强求。
　　具体的了解一下这个层的关系，以及构建架构时上文提到的需要涉及到的问题。

　　

1． Presentation Tier

　　表示层分层两层，

UI Components 可以直接看作是 HTML，UI Process 这里不是

MVC，而是 code-behind 类。 在表示层，就我所碰到需要处理的问题有：
　　

l)MVC (Model-Views-Controller)

　　

Asp.net 下是否需要使用 MVC 一直是一个有争议的问题。 Asp.net 的特点是事件驱动

与

Code-behind，Code-behind 本身就可以理解是 MVC 中的 Controller，但是没有体