.NET Framework
摘要:为什么我们就要使用 n(物理)层体系结构来构建系统?这是一篇基础性的文章,介绍了人们对于软件的一种理念,即当我们面对新项目时往往将系统明确地分为三个物理层次:表现层、业务逻辑层和数据访问或资源层。然而,对于循规蹈矩的做事方式应当重新审视。
有些事物是如此坚定地挺进了我们的通俗文化之中,以至于不发生灾难性的事故就无法将其摈弃,即使它们早已不能适应我们的生活。这样的例子在法律界比比皆是,在当今时代或其他时代美国的市、州甚至联邦政府针对无意义的书籍都有相关的法律(据说,在亚利桑那州的某个小镇上,在公路中间倒车是违法的)。这不禁使人联想到一个老笑话:
一个刚结婚的男人看到妻子正在准备晚餐要吃的烤肉。他吃惊地发现,妻子在将肉放到烤盘中前,分别在两端切掉了大约两英寸的肉,然后扔掉。而当男人对妻子的这一行为表示惊讶时,妻子回答道“这会使肉的味道更好。而且,我的妈妈也总是这样做”。他好奇地给岳母打了电话,问她是否也切掉烤肉的两端,以及这样做的原因。“因为这会使肉的味道更好。而且,我的妈妈也总是这样做”。男人决心找出这个习惯的源头,于是又给妻子的外婆打了电话,当外婆回答她在准备烤肉的时候也要切掉肉的两端时,男人又接着问为什么。外婆立刻回答说“因为我的盘子太小了,装不下整块肉”。
毫无疑问,对于这种明显的循规蹈矩的做事方式应当重新审视。但遗憾的是,其他情况并不都如此显而易见。
例如,为什么我们就要使用 n(物理)层体系结构来构建系统?这是一篇基础性的文章,介绍了人们对于软件的一种理念,即当我们面对新项目时往往将系统明确地分为三个物理层次:表现层,用以处理所有用户输入和数据显示问题;业务逻辑层,存放所有“业务逻辑”(本身是一个完全无定性的名词,可准确表示说话者希望其表达的意思);数据访问或资源层,存放用于检索、修改或存储数据的所有代码。当被问道为什么要这样做时,许多人只能说出最普通的答案,“因为我的老师(或前任主管或刚读过的一本书)总是这种做”。与普通的进程内调用相比,跨物理层通信会带来高达三到六个数量级的巨大性能成本,两者的差距就相当于一个是到楼下杂货店而另一个是到冥王星。(请参阅《Effective Enterprise Java》(有效的企业 Java)第 17 条)。仅仅因为妈妈总是这样做,我们就要丢掉好肉… 嗯 CPU 周期吗?
归根结底,请记住以物理分层的方式构建应用程序并不是开发人员的唯一选择。举个例子,想想 UNIX 开发人员早已熟知而 .NET 开发人员随着 Microsoft Windows PowerShell 的即将推出才开始领悟到的一个真谛:将小部件分割成可以互馈的片段可以创建出一些功能极强的合成工具,避免了用来维护复杂应用程序所需的相应复杂性。例如,对一般的 C# 或 Visual Basic 语言开发人员而言,创建一个能够在文本文件中搜索并替换某个字符串序列的工具可能是件容易的工作,而这对于掌握 PowerShell 的人则更加显得微不足道,因为它只需串联几个“cmdlets”:其中一个用于遍历文件,另一个用于搜索文件内容并用新文本替换所搜索的文本,第三个用于将新内容写入磁盘。这是一个非常好的模型。具体而言,由于每个组件都能够专注于特定的任务(遍历、搜索、写入),从而简化了它们的维护和设计工作。
在匆忙地对 n(物理)层模型做出审判之前,它应该得到一次救赎的机会。对于初学者,我们可以对过于通用的“n 层”一词的使用稍加重新界定,并指出“物理层”和“逻辑层”的重要区别。(请参阅 Martin Fowler 的《Patterns of Enterprise Application Architecture》(企业应用体系结构的模式),阅读关于这一主题的完整论述。)
“逻辑层”是对软件的逻辑分割,是在开发人员级对各关注点的基础分割,这样我们可以更加容易地划分系统的职责。这在 [POSA1] 中有进一步的论述。在这本书中谈及逻辑层模式时讲到,使用逻辑层“有助于构筑可以分解为子任务组(每组子任务处于某个抽象级别)的应用程序”。换句话说,它是对各关注点的典型分割方式:将企业系统中所涉及的各种任务(包括检索数据、存储数据、针对数据执行业务规则、显示数据、搜集输入值等等)分割为组件或子节,以便我们能够更加轻松地跟踪在何时何处发生了什么。当然,最为常见的方式是将任务分为“表现”、“逻辑”和“数据访问”(逻辑)层。但请注意,我们并没有立即假定每个逻辑层将在“哪里”运行,目前还没有。
而另一方面,“物理层”是硬件(通常是某种形式的计算机)的物理分层,我们系统的一部分或全部可以运行于其上。传统的客户机/服务器计算(即写入可以针对运行于单独服务器上的数据库执行 SQL 语句的程序)是一个由两个物理层构成的系统。我们每天都享用的万维网也是在两(物理)层方法的基础上构建的,其中一个物理层(即客户机)位于某人的家中或办公室内并远程访问位于某处服务器机房中的另一个物理层。这样的例子数不胜数。
这似乎有些文不切题。归根结底,表现层不总是在客户计算机上吗?数据访问层不总是在数据库服务器上吗?而业务逻辑层不总是在前两者之间某处的计算机上吗?我们来进一步研究一下基于 Web 的典型三(物理)层应用程序模型:
| • | 基于 Web 的应用程序中的“表现”逻辑层是 Web 浏览器,因此不在我们的掌控之中。浏览器将要显示的 HTML 通常必须从服务器内所运行的某种形式(ASP 或 ASP.NET)的代码组件中生成并被发送给浏览器。这就意味着“表现”逻辑层现在要跨两个物理层进行分割。 |
| • | 同样,“数据访问“逻辑层也并不是完全位于数据库物理层,因为用于访问和处理数据的命令(即 SQL)必须从数据库层之外被生成和发送。这就意味着,与表现逻辑层一样,数据访问逻辑层代码现在至少要跨两个物理层进行分割。 |
这使我们认识到,尽管人们似乎很自然地认为表现逻辑层是在客户机物理层上运行,而实际上这种情况仅存在于目前称为“富客户机”或&ld
【中国下载站】【设为主页】【收藏本页】【打印本文】【回到顶部】【关闭此页】