从N层到.NET具体剖析原理(1)
核心提示:讨论 Microsoft .net 的利用程序设计和所需的更改:检验从使用 Microsoft Windows DNA 构建 N 层利用程序中学到的结构知识,和如何将这些知识利用到使用 Microsoft .NET 框架构建的利用程序,并且为使用 XML Web Services 的利用程序提供体系结构方面的建议。
简介
如今,N 层利用程序已成为构建企业软件的标准。对大多数人来讲,N 层利用程序就是被分成多个独立的逻辑部份的利用程序。最多见的选择是分为3个部份:表示、业务逻辑和数据,固然还可能存在其他的划分方法。N 层利用程序最初是为了解决与传统的客户端/服务器利用程序相干的题目而出现的,但是,随着 Web 时期的到来,这1体系结构开始成为新开发项目的主流。
Microsoft Windows? DNA 技术已成为 N 层利用程序的非常成功的基础。Microsoft .NET 框架也为构建 N 层利用程序提供了坚实的平台。但是,。NET 所带来的变化使结构设计职员应当重新考虑他们在 Windows DNA 领域中所学的有关设计 N 层利用程序的某些知识。更重要的是,对内置于 .NET 框架的 XML Web services 的基本支持答应开发职员构建突破传统 N 层方法的新利用程序。要了解如何更好地构建 .NET 利用程序的体系结构,您需要了解这1新领域中产生了哪些变化,和如何充分利用这些变化。
本文将对这些题目进行讨论。首先回顾1下在使用 Windows DNA 构建 N 层利用程序中学到的关键体系结构知识。然后,再按同1顺序将这些知识利用到使用 .NET 框架构建利用程序的进程中,从而对它们进行检验。最后1部份对使用 XML Web services 的利用程序的体系结构提供了1些建议。
Windows DNA 环境
将利用程序恐解成多个逻辑部份是很有铀的。将1个大软件分成几个小的部份会更利于软件的构建、重复利用和修改,对适应不同的技术或不同典业务组织也很有帮助。同时,还有1些综合因素需要考虑。固然模块化和重复使用性很有效,但它们可能会导致赢用程序不能象使用其他方法那样安全、易治理和快速。本节将回顾1些从使用 Windows DNA牸际豕菇?N 层利用程序的普遍经验中所取得的基1咎逑到峁怪?丁?
编写业务逻辑
Windows DNA 利用程序通常使用以下3种实现方式中的1种或多种方式来实现其业务逻辑:
●ASP 页
●COM 组峻,可能使用 COM+ 提供的其他服务
●在 DBMS 中运行的存储进程
1般来讲,在 ASP 页中编写过量的业务逻辑其实不是1个好办法。由于必须使用简单的语言,例如 Microsoft Visual Basic? Script (VBScript),而且每次履行时都要解释代码,这会对性能造成影响。而且 ASP 页中的代码不好保护,主要是由于业务逻辑通常与创建用户界面的表示代码混合在1起。
鉴于这类情况,建议在编写中间层业务逻辑时,将业务逻辑当作 COM 对象来实现。这类方法比编写纯洁的 ASP 利用程序要稍微复杂1点,但是可使用全功能语言来天生编译好的可履行文件,因此其结果要快很多。将业务逻辑包装在 COM 对象中还可以将此代码与包括在 ASP 页中的表示代码完全分隔开来,从而使利用程序更容易于保护。
从 COM 到 COM+,其体系结构相差无几。但是,正如很多 Windows DNA 体系结构设计职员所了解的,除非真正需要,否则不应使用 COM+ 提供的核心服务,如事务、实时 (JIT) 激活、基于角色的安全性和线程服务等。使用其他开发平台提供的 COM+ 或类似服务自然会导致利用程序速度更慢、更复杂。只有在以下情况下使用 COM+ 才故意义:
●需要逾越不同资源治理器(如 Microsoft SQL Server? 和 Oracle)的散布式事务。
●利用程序可以有效地利用基于角色的安全性。
●可以增强 Microsoft Visual Basic? 6.0 的线程操纵。
●JIT 激活能够进步性能;浏览器客户端很少出现这类情况,由于 ASP 页是通过 JIT 有效激活的。
●COM+ 的配置上风大大简化了利用程序的部署。
编写业务逻辑的第3种方式是,创建1些作为存储进程在数据库治理系统 (DBMS) 中运行的代码。虽然使用存储进程的主要缘由是将数据库架构的具体信息与业务逻辑分隔开以简化代码的治理和进步安全性,但代码与数据如此接近也有助于优化性能。那些必须独立于 DBMS 的利用程序(例如由独立的软件供给商创建的利用程序)通常要避免使用这类方法,由于它会将利用程序锁定到某个特定的数据库系统中。存储进程的编写和调试可能会比 COM 对象的编写和调试难,而且此方法会减少重复使用代码的机会,这是由于 COM 对象通常比存储进程更容易于重复使用。但是大多数自定义利用程序依然连接到最初创建它们的 DBMS 上,因此使用存储进程的性能上风还是很大的。鉴于这类情况,那些必须尽可能运行良好的 Windows DNA 利用程序通常对部份或全部的业务逻辑都使用存储进程。
构建客户端
Windows DNA 既支持用 Visual Basic 等语言编写的本地 Windows 客户端,也支持浏览器客户端。浏览器客户真个局限性较大,特别同时将 Microsoft Internet Explorer 和 Netscape 作为浏览器时。因此,利用程序通常同时具有浏览器客户端和本地 Windows 客户端。浏览器客户端提供的界面很有限,但用它可以方便地访问 Internet,而 Windows 客户端能提供全功能的界面。使用可下载的 Microsoft ActiveX? 控件可以创建更复杂的浏览器界面,但必须确保浏览器是 Internet Explorer,并且用户愿意信任利用程序的创建者。
治理浏览器利用程序中的状态
ASP 利用程序可使用几个不同的机制来保护服务器上客户端要求之间的信息。但是 Windows DNA 中有1条严格的规则,假设利用程序在两台或多台机器之间平衡负载,则尽对不能使用 ASP Session 对象存储每个客户真个状态。ASP 的 Session 对象被锁定在1台机器上,因此不能用于负载平衡的利用程序。
ASP Session 对象和 ASP Application 对象还有另1个限制。使用它们中的任何1个来存储 ADO 记录集都会大大下降可伸缩性,由于它限制了利用程序开发多线程的能力。因此,在这两个对象的任何1个中存储记录集都不是好办法。
散布式通讯
在 Windows DNA 中,选择运行在不同机器上的组件的通讯方式非常简单:DCOM 可以说是唯1的选择。单纯从体系结构上来看,DCOM 是 COM 的简单扩大。但实际上,DCOM 还有很多其他含义,其中包括:
●由于实际上是其自有协议,因此使用 DCOM 与远程 COM+ 对象进行通讯非常直接。
●只要配置正确,DCOM 将是非常安全的协议。但是要实现这类配置其实不轻易,因此该协议不太轻易使用。虽然如此,DCOM 本身仍能提供很好的散布式身份验证、数据完全性和数据保密性,特别是在 Windows 2000 域内。
●由于 DCOM 需要打开任意端口,因此不合适与防火墙配合使用。所以,对必须通过 Internet 进行通讯的利用程序,1般不能使用 DCOM.
访问存储数据
可以将使用 ADO 构建的数据访问体系结构分为两类:轻型和重型。轻型 ADO 客户端尽可能简短地保持数据库连接,并使用存储进程写进数据库。轻型客户端使用以下3种方法之1检索数据:
●通过使用只读的、仅向前游标填充记录集;
●通过存储进程输出参数;
●使用数据流(在 ADO 的较新版本中)。
重型客户端则会较长时间地保持数据库连接。这类利用程序依托于开放式连接,和那些连接所答应的有状态的服务器端游标,以:
●使记录集能够直接访问其他用户或利用程序所做的更改;
●启用守旧式锁定;
●尽可能减少复制到 ADO 客户真个数据量,以减少网络通讯量。与轻型客户端不同,使用服务器端游标的客户端可以将查询结果保存在数据库内,直到真正需要这些数据时再取出。另外,这类方法向记录集复制的元数据较少,而把更多的数据保存在数据库中。
轻型利用程序最具伸缩性,由于它们最有效地使用了数据库连接这1稀有资源。相比之下,重型利用程序必须保持长时间有效的数据库连接,由于这是有状态的服务器端游标所要求的。这就大大地限制了利用程序的可伸缩性,特别不适用于 Internet 服务器利用程序。虽然使用 ADO 开发重型利用程序可能更简单,但通常这其实不是最好选择。
ADO 也不是特别适用于处理 XML 文档等分层数据。ADO 完成此项工作的功能用法复杂,且不容易理解。一样,ADO 仅为访问 SQL Server 2000 的 XML 功能提供有限支持,因此,Windows DNA 利用程序通常都避免使用 ADO 处理分层数据。
唐山网站建设www.fw8.netTAG:数据,程序,客户端,逻辑,体系结构
评论加载中...
|