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,但是没有体