Sections:
|
PetShop的系统架构设计Filed under: Design & Pattern — bruce zhang @ 4:55 pm
《解剖PetShop》系列之一 前言:PetShop是一个范例,微软用它来展示.Net企业系统开发的能力。业界有许多.Net与J2EE之争,许多数据是从微软的PetShop和Sun的PetStore而来。这种争论不可避免带有浓厚的商业色彩,对于我们开发人员而言,没有必要过多关注。然而PetShop随着版本的不断更新,至现在基于.Net 2.0的PetShop4.0为止,整个设计逐渐变得成熟而优雅,却又很多可以借鉴之处。PetShop是一个小型的项目,系统架构与代码都比较简单,却也凸现了许多颇有价值的设计与开发理念。本系列试图对PetShop作一个全方位的解剖,依据的代码是PetShop4.0,可以从链接http://msdn.microsoft.com/library/default.asp?url=/library/en-us/dnbda/html/bdasamppet4.asp中获得。 一、PetShop的系统架构设计 在软件体系架构设计中,分层式结构是最常见,也是最重要的一种结构。微软推荐的分层式结构一般分为三层,从下至上分别为:数据访问层、业务逻辑层(又或成为领域层)、表示层,如图所示:
数据访问层:有时候也称为是持久层,其功能主要是负责数据库的访问。简单的说法就是实现对数据表的Select,Insert,Update,Delete的操作。如果要加入ORM的元素,那么就会包括对象和数据表之间的mapping,以及对象实体的持久化。在PetShop的数据访问层中,并没有使用ORM,从而导致了代码量的增加,可以看作是整个设计实现中的一大败笔。 业务逻辑层:是整个系统的核心,它与这个系统的业务(领域)有关。以PetShop为例,业务逻辑层的相关设计,均和网上宠物店特有的逻辑相关,例如查询宠物,下订单,添加宠物到购物车等等。如果涉及到数据库的访问,则调用数据访问层。 表示层:是系统的UI部分,负责使用者与整个系统的交互。在这一层中,理想的状态是不应包括系统的业务逻辑。表示层中的逻辑代码,仅与界面元素有关。在PetShop中,是利用ASP.Net来设计的,因此包含了许多Web控件和相关逻辑。 分层式结构究竟其优势何在?Martin Fowler在《Patterns of Enterprise Application Architecture》一书中给出了答案: 概括来说,分层式设计可以达至如下目的:分散关注、松散耦合、逻辑复用、标准定义。 一个好的分层式结构,可以使得开发人员的分工更加明确。一旦定义好各层次之间的接口,负责不同逻辑设计的开发人员就可以分散关注,齐头并进。例如UI人员只需考虑用户界面的体验与操作,领域的设计人员可以仅关注业务逻辑的设计,而数据库设计人员也不必为繁琐的用户交互而头疼了。每个开发人员的任务得到了确认,开发进度就可以迅速的提高。 松散耦合的好处是显而易见的。如果一个系统没有分层,那么各自的逻辑都紧紧纠缠在一起,彼此间相互依赖,谁都是不可替换的。一旦发生改变,则牵一发而动全身,对项目的影响极为严重。降低层与层间的依赖性,既可以良好地保证未来的可扩展,在复用性上也是优势明显。每个功能模块一旦定义好统一的接口,就可以被各个模块所调用,而不用为相同的功能进行重复地开发。 进行好的分层式结构设计,标准也是必不可少的。只有在一定程度的标准化基础上,这个系统才是可扩展的,可替换的。而层与层之间的通信也必然保证了接口的标准化。 “金无足赤,人无完人”,分层式结构也不可避免具有一些缺陷: 前面提到,PetShop的表示层是用ASP.Net设计的,也就是说,它应是一个BS系统。在.Net中,标准的BS分层式结构如下图所示:
随着PetShop版本的更新,其分层式结构也在不断的完善,例如PetShop2.0,就没有采用标准的三层式结构,如图三:
从图中我们可以看到,并没有明显的数据访问层设计。这样的设计虽然提高了数据访问的性能,但也同时导致了业务逻辑层与数据访问的职责混乱。一旦要求支持的数据库发生变化,或者需要修改数据访问的逻辑,由于没有清晰的分层,会导致项目作大的修改。而随着硬件系统性能的提高,以及充分利用缓存、异步处理等机制,分层式结构所带来的性能影响几乎可以忽略不计。 PetShop3.0纠正了此前层次不明的问题,将数据访问逻辑作为单独的一层独立出来:
PetShop4.0基本上延续了3.0的结构,但在性能上作了一定的改进,引入了缓存和异步处理机制,同时又充分利用了ASP.Net 2.0的新功能MemberShip,因此PetShop4.0的系统架构图如下所示:
比较3.0和4.0的系统架构图,其核心的内容并没有发生变化。在数据访问层(DAL)中,仍然采用DAL Interface抽象出数据访问逻辑,并以DAL Factory作为数据访问层对象的工厂模块。对于DAL Interface而言,分别有支持MS-SQL的SQL Server DAL和支持Oracle的Oracle DAL具体实现。而Model模块则包含了数据实体对象。其详细的模块结构图如下所示:
可以看到,在数据访问层中,完全采用了“面向接口编程”思想。抽象出来的IDAL模块,脱离了与具体数据库的依赖,从而使得整个数据访问层利于数据库迁移。DALFactory模块专门管理DAL对象的创建,便于业务逻辑层访问。SQLServerDAL和OracleDAL模块均实现IDAL模块的接口,其中包含的逻辑就是对数据库的Select,Insert,Update和Delete操作。因为数据库类型的不同,对数据库的操作也有所不同,代码也会因此有所区别。 此外,抽象出来的IDAL模块,除了解除了向下的依赖之外,对于其上的业务逻辑层,同样仅存在弱依赖关系,如下图所示:
图七中BLL是业务逻辑层的核心模块,它包含了整个系统的核心业务。在业务逻辑层中,不能直接访问数据库,而必须通过数据访问层。注意图中对数据访问业务的调用,是通过接口模块IDAL来完成的。既然与具体的数据访问逻辑无关,则层与层之间的关系就是松散耦合的。如果此时需要修改数据访问层的具体实现,只要不涉及到IDAL的接口定义,那么业务逻辑层就不会受到任何影响。毕竟,具体实现的SQLServerDAL和OracalDAL根本就与业务逻辑层没有半点关系。 因为在PetShop 4.0中引入了异步处理机制。插入订单的策略可以分为同步和异步,两者的插入策略明显不同,但对于调用者而言,插入订单的接口是完全一样的,所以PetShop 4.0中设计了IBLLStrategy模块。虽然在IBLLStrategy模块中,仅仅是简单的IOrderStategy,但同时也给出了一个范例和信息,那就是在业务逻辑的处理中,如果存在业务操作的多样化,或者是今后可能的变化,均应利用抽象的原理。或者使用接口,或者使用抽象类,从而脱离对具体业务的依赖。不过在PetShop中,由于业务逻辑相对简单,这种思想体现得不够明显。也正因为此,PetShop将核心的业务逻辑都放到了一个模块BLL中,并没有将具体的实现和抽象严格的按照模块分开。所以表示层和业务逻辑层之间的调用关系,其耦合度相对较高:
在图五中,各个层次中还引入了辅助的模块,如数据访问层的Messaging模块,是为异步插入订单的功能提供,采用了MSMQ(Microsoft Messaging Queue)技术。而表示层的CacheDependency则提供缓存功能。这些特殊的模块,我会在此后的文章中详细介绍。 15 Comments »
PetShop数据访问层之数据库访问设计Filed under: Design & Pattern — bruce zhang @ 1:50 pm
《解剖PetShop》系列之二 二、PetShop数据访问层之数据库访问设计 在PetShop中,系统需要处理的数据库对象分为两类:一是数据实体,对应数据库中相应的数据表。它们没有行为,仅用于表现对象的数据。这些实体类都被放到Model程序集中,例如数据表Order对应的实体类OrderInfo,其类图如下:
这些对象并不具有持久化的功能,简单地说,它们是作为数据的载体,便于业务逻辑针对相应数据表进行读/写操作。虽然这些类的属性分别映射了数据表的列,而每一个对象实例也恰恰对应于数据表的每一行,但这些实体类却并不具备对应的数据库访问能力。 由于数据访问层和业务逻辑层都将对这些数据实体进行操作,因此程序集Model会被这两层的模块所引用。 第二类数据库对象则是数据的业务逻辑对象。这里所指的业务逻辑,并非业务逻辑层意义上的领域(domain)业务逻辑(从这个意义上,我更倾向于将业务逻辑层称为“领域逻辑层”),一般意义上说,这些业务逻辑即为基本的数据库操作,包括Select,Insert,Update和Delete。由于这些业务逻辑对象,仅具有行为而与数据无关,因此它们均被抽象为一个单独的接口模块IDAL,例如数据表Order对应的接口IOrder:
将数据实体与相关的数据库操作分离出来,符合面向对象的精神。首先,它体现了“职责分离”的原则。将数据实体与其行为分开,使得两者之间依赖减弱,当数据行为发生改变时,并不影响Model模块中的数据实体对象,避免了因一个类职责过多、过大,从而导致该类的引用者发生“灾难性”的影响。其次,它体现了“抽象”的精神,或者说是“面向接口编程”的最佳体现。抽象的接口模块IDAL,与具体的数据库访问实现完全隔离。这种与实现无关的设计,保证了系统的可扩展性,同时也保证了数据库的可移植性。在PetShop中,可以支持SQL Server和Oracle,那么它们具体的实现就分别放在两个不同的模块SQLServerDAL、OracleDAL中。 以Order为例,在SQLServerDAL、OracleDAL两个模块中,有不同的实现,但它们同时又都实现了IOrder接口,如图:
从数据库的实现来看,PetShop体现出了没有ORM框架的臃肿与丑陋。由于要对数据表进行Insert和Select操作,以SQL Server为例,就使用了SqlCommand,SqlParameter,SqlDataReader等对象,以完成这些操作。尤其复杂的是Parameter的传递,在PetShop中,使用了大量的字符串常量来保存参数的名称。此外,PetShop还专门为SQL Server和Oracle提供了抽象的Helper类,包装了一些常用的操作,如ExecuteNonQuery、ExecuteReader等方法。 在没有ORM的情况下,使用Helper类是一个比较好的策略,利用它来完成数据库基本操作的封装,可以减少很多和数据库操作有关的代码,这体现了对象复用的原则。PetShop将这些Helper类统一放到DBUtility模块中,不同数据库的Helper类暴露的方法基本相同,只除了一些特殊的要求,例如Oracle中处理bool类型的方式就和SQL Server不同,从而专门提供了OraBit和OraBool方法。此外,Helper类中的方法均为static方法,以利于调用。OracleHelper的类图如下:
对于数据访问层来说,最头疼的是SQL语句的处理。在早期的CS结构中,由于未采用三层式架构设计,数据访问层和业务逻辑层是紧密糅合在一起的,因此,SQL语句遍布与系统的每一个角落。这给程序的维护带来极大的困难。此外,由于Oracle使用的是PL-SQL,而SQL Server和Sybase等使用的是T-SQL,两者虽然都遵循了标准SQL的语法,但在很多细节上仍有区别,如果将SQL语句大量的使用到程序中,无疑为可能的数据库移植也带来了困难。 最好的方法是采用存储过程。这种方法使得程序更加整洁,此外,由于存储过程可以以数据库脚本的形式存在,也便于移植和修改。但这种方式仍然有缺陷。一是存储过程的测试相对困难。虽然有相应的调试工具,但比起对代码的调试而言,仍然比较复杂且不方便。二是对系统的更新带来障碍。如果数据库访问是由程序完成,在.Net平台下,我们仅需要在修改程序后,将重新编译的程序集xcopy到部署的服务器上即可。如果使用了存储过程,出于安全的考虑,必须有专门的DBA重新运行存储过程的脚本,部署的方式受到了限制。 我曾经在一个项目中,利用一个专门的表来存放SQL语句。如要使用相关的SQL语句,就利用关键字搜索获得对应语句。这种做法近似于存储过程的调用,但却避免了部署上的问题。然而这种方式却在性能上无法得到保证。它仅适合于SQL语句较少的场景。不过,利用良好的设计,我们可以为各种业务提供不同的表来存放SQL语句。同样的道理,这些SQL语句也可以存放到XML文件中,更有利于系统的扩展或修改。不过前提是,我们需要为它提供专门的SQL语句管理工具。 SQL语句的使用无法避免,如何更好的应用SQL语句也无定论,但有一个原则值得我们遵守,就是“应该尽量让SQL语句尽存在于数据访问层的具体实现中”。 当然,如果应用ORM,那么一切就变得不同了。因为ORM框架已经为数据访问提供了基本的Select,Insert,Update和Delete操作了。例如在NHibernate中,我们可以直接调用ISession对象的Save方法,来Insert(或者说是Create)一个数据实体对象: 没有SQL语句,也没有那些烦人的Parameters,甚至不需要专门去考虑事务。此外,这样的设计,也是与数据库无关的,NHibernate可以通过Dialect(方言)的机制支持不同的数据库。唯一要做的是,我们需要为OrderInfo定义hbm文件。 当然,ORM框架并非是万能的,面对纷繁复杂的业务逻辑,它并不能完全消灭SQL语句,以及替代复杂的数据库访问逻辑,但它却很好的体现了“80/20(或90/10)法则”(也被称为“帕累托法则”),也就是说:花比较少(10%-20%)的力气就可以解决大部分(80%-90%)的问题,而要解决剩下的少部分问题则需要多得多的努力。至少,那些在数据访问层中占据了绝大部分的CRUD操作,通过利用ORM框架,我们就仅需要付出极少数时间和精力来解决它们了。这无疑缩短了整个项目开发的周期。 还是回到对PetShop的讨论上来。现在我们已经有了数据实体,数据对象的抽象接口和实现,可以说有关数据库访问的主体就已经完成了。留待我们的还有两个问题需要解决: 在PetShop中,要创建的数据对象包括Order,Product,Category,Inventory,Item。在前面的设计中,这些对象已经被抽象为对应的接口,而其实现则根据数据库的不同而有所不同。也就是说,创建的对象有多种类别,而每种类别又有不同的实现,这是典型的抽象工厂模式的应用场景。而上面所述的两个问题,也都可以通过抽象工厂模式来解决。标准的抽象工厂模式类图如下:
例如,创建SQL Server的Order对象如下: 要考虑到数据库的可移植性,则factory必须作为一个全局变量,并在主程序运行时被实例化。但这样的设计虽然已经达到了“封装变化”的目的,但在创建PetShopFactory对象时,仍不可避免的出现了具体的类SQLServerFactory,也即是说,程序在这个层面上产生了与SQLServerFactory的强依赖。一旦整个系统要求支持Oracle,那么还需要修改这行代码为: 修改代码的这种行为显然是不可接受的。解决的办法是“依赖注入”。“依赖注入”的功能通常是用专门的IoC容器提供的,在Java平台下,这样的容器包括Spring,PicoContainer等。而在.Net平台下,最常见的则是Spring.Net。不过,在PetShop系统中,并不需要专门的容器来实现“依赖注入”,简单的做法还是利用配置文件和反射功能来实现。也就是说,我们可以在web.config文件中,配置好具体的Factory对象的完整的类名。然而,当我们利用配置文件和反射功能时,具体工厂的创建就显得有些“画蛇添足”了,我们完全可以在配置文件中,直接指向具体的数据库对象实现类,例如PetShop.SQLServerDAL.IOrder。那么,抽象工厂模式中的相关工厂就可以简化为一个工厂类了,所以我将这种模式称之为“具有简单工厂特质的抽象工厂模式”,其类图如下:
DataAccess类完全取代了前面创建的工厂类体系,它是一个sealed类,其中创建各种数据对象的方法,均为静态方法。之所以能用这个类达到抽象工厂的目的,是因为配置文件和反射的运用,如下的代码片断所示: public static PetShop.IDAL.IOrder CreateOrder() 在PetShop中,这种依赖配置文件和反射创建对象的方式极其常见,包括IBLLStategy、CacheDependencyFactory等等。这些实现逻辑散布于整个PetShop系统中,在我看来,是可以在此基础上进行重构的。也就是说,我们可以为整个系统提供类似于“Service Locator”的实现: public static object LocateDALObject(string className) 那么和所谓“依赖注入”相关的代码都可以利用ServiceLocator来完成。例如类DataAccess就可以简化为: 通过ServiceLocator,将所有与配置文件相关的namespace值统一管理起来,这有利于各种动态创建对象的管理和未来的维护。 PetShop数据访问层之消息处理Filed under: Design & Pattern — bruce zhang @ 12:11 pm
《解剖PetShop》系列之三 在进行系统设计时,除了对安全、事务等问题给与足够的重视外,性能也是一个不可避免的问题所在,尤其是一个B/S结构的软件系统,必须充分地考虑访问量、数据流量、服务器负荷的问题。解决性能的瓶颈,除了对硬件系统进行升级外,软件设计的合理性尤为重要。
在对消息接口的实现中,考虑到未来的扩展中会有其他的数据对象会使用MSMQ,因此定义了一个Queue的基类,实现消息Receive和Send的基本操作: public void Send(OrderInfo orderMessage)
注意在Order类的Receive()方法中,是用new关键字而不是override关键字来重写其父类PetShopQueue的Receive()虚方法。因此,如果是实例化如下的对象,将会调用PetShopQueue的Receive()方法,而不是子类Order的Receive()方法:
在类QueueAccess中,通过CreateOrder()方法利用反射技术创建正确的IOrder类型对象: Order order = new Order(); int processedItems = 0; ArrayList queueOrders = new ArrayList(); using (TransactionScope ts = new TransactionScope(TransactionScopeOption.Required, tsTimeout)) //update elapsed time //batch complete or MSMQ receive timed out Console.WriteLine("(Thread Id " + Thread.CurrentThread.ManagedThreadId + ") batch finished, " + processedItems + " items, in " + elapsedTime.ToString() + " seconds."); // Insert the order (a)synchrounously based on configuration
在PetShop.BLL.Order类中,仍然利用配置文件来动态创建IOrderStategy对象: // Using the evidence given in the config file load the appropriate assembly and class
Microsoft Messaging Queue(MSMQ)技术除用于异步处理以外,它主要还是一种分布式处理技术。分布式处理中,一个重要的技术要素就是有关消息的处理,而在System.Messaging命名空间中,已经提供了Message类,可以用于承载消息的传递,前提上消息的发送方与接收方在数据定义上应有统一的接口规范。
首先Dealer的数据通过MSMQ传递到MSMQ Server,此时可以将数据插入到SQL Server数据库中,同时利用FTP将数据传送到专门的文件服务器上。然后利用IBM的EAI技术(企业应用集成,Enterprise Application Itegration)定期将文件服务器中的文件,利用接口规范写入到EAI数据库服务器中,并最终写道EBS的Oracle数据库中。 《解剖PetShop》系列之四 四 PetShop之ASP.NET缓存 如果对微型计算机硬件系统有足够的了解,那么我们对于Cache这个名词一定是耳熟能详的。在CPU以及主板的芯片中,都引入了这种名为高速缓冲存储器(Cache)的技术。因为Cache的存取速度比内存快,因而引入Cache能够有效的解决CPU与内存之间的速度不匹配问题。硬件系统可以利用Cache存储CPU访问概率高的那些数据,当CPU需要访问这些数据时,可以直接从Cache中读取,而不必访问存取速度相对较慢的内存,从而提高了CPU的工作效率。软件设计借鉴了硬件设计中引入缓存的机制以改善整个系统的性能,尤其是对于一个数据库驱动的Web应用程序而言,缓存的利用是不可或缺的,毕竟,数据库查询可能是整个Web站点中调用最频繁但同时又是执行最缓慢的操作之一,我们不能被它老迈的双腿拖缓我们前进的征程。缓存机制正是解决这一缺陷的加速器。 4.1 ASP.NET缓存概述 作为.Net框架下开发Web应用程序的主打产品,ASP.NET充分考虑了缓存机制。通过某种方法,将系统需要的数据对象、Web页面存储在内存中,使得Web站点在需要获取这些数据时,不需要经过繁琐的数据库连接、查询和复杂的逻辑运算,就可以“触手可及”,如“探囊取物”般容易而快速,从而提高整个Web系统的性能。 ASP.NET提供了两种基本的缓存机制来提供缓存功能。一种是应用程序缓存,它允许开发者将程序生成的数据或报表业务对象放入缓存中。另外一种缓存机制是页输出缓存,利用它,可以直接获取存放在缓存中的页面,而不需要经过繁杂的对该页面的再次处理。 应用程序缓存其实现原理说来平淡无奇,仅仅是通过ASP.NET管理内存中的缓存空间。放入缓存中的应用程序数据对象,以键/值对的方式存储,这便于用户在访问缓存中的数据项时,可以根据key值判断该项是否存在缓存中。 放入在缓存中的数据对象其生命周期是受到限制的,即使在整个应用程序的生命周期里,也不能保证该数据对象一直有效。ASP.NET可以对应用程序缓存进行管理,例如当数据项无效、过期或内存不足时移除它们。此外,调用者还可以通过CacheItemRemovedCallback委托,定义回调方法使得数据项被移除时能够通知用户。 在.Net Framework中,应用程序缓存通过System.Web.Caching.Cache类实现。它是一个密封类,不能被继承。对于每一个应用程序域,都要创建一个Cache类的实例,其生命周期与应用程序域的生命周期保持一致。我们可以利用Add或Insert方法,将数据项添加到应用程序缓存中,如下所示: 我们还可以为应用程序缓存添加依赖项,使得依赖项发生更改时,该数据项能够从缓存中移除: 与之对应的是缓存中数据项的移除。前面提到ASP.NET可以自动管理缓存中项的移除,但我们也可以通过代码编写的方式显式的移除相关的数据项: 相对于应用程序缓存而言,页输出缓存的应用更为广泛。它可以通过内存将处理后的ASP.NET页面存储起来,当客户端再一次访问该页面时,可以省去页面处理的过程,从而提高页面访问的性能,以及Web服务器的吞吐量。例如,在一个电子商务网站里,用户需要经常查询商品信息,这个过程会涉及到数据库访问以及搜索条件的匹配,在数据量较大的情况下,如此的搜索过程是较为耗时的。此时,利用页输出缓存就可以将第一次搜索得到的查询结果页存储在缓存中。当用户第二次查询时,就可以省去数据查询的过程,减少页面的响应时间。 页输出缓存分为整页缓存和部分页缓存。我们可以通过@OutputCache指令完成对Web页面的输出缓存。它主要包含两个参数:Duration和VaryByParam。Duration参数用于设置页面或控件进行缓存的时间,其单位为秒。如下的设置表示缓存在60秒内有效: 只要没有超过Duration设置的期限值,当用户访问相同的页面或控件时,就可以直接在缓存中获取。 如此一来,ASP.NET会对txtCity控件的值进行判断,只有输入的值与缓存值相同,才从缓存中取出相应的值。这就有效地避免了因为值的不同而导致输出错误的数据。 利用缓存的机制对性能的提升非常明显。通过ACT(Application Center Test)的测试,可以发现设置缓存后执行的性能比未设置缓存时的性能足足提高三倍多。 引入缓存看来是提高性能的“完美”解决方案,然而“金无足赤,人无完人”,缓存机制也有缺点,那就是数据过期的问题。一旦应用程序数据或者页面结果值发生的改变,那么在缓存有效期范围内,你所获得的结果将是过期的、不准确的数据。我们可以想一想股票系统利用缓存所带来的灾难,当你利用错误过期的数据去分析股市的风云变幻时,你会发现获得的结果真可以说是“失之毫厘,谬以千里”,看似大好的局面就会像美丽的泡沫一样,用针一戳,转眼就消失得无影无踪。 那么我们是否应该为了追求高性能,而不顾所谓“数据过期”所带来的隐患呢?显然,在类似于股票系统这种数据更新频繁的特定场景下,数据过期的糟糕表现甚至比低效的性能更让人难以接受。故而,我们需要在性能与数据正确性间作出权衡。所幸的是,.Net Framework 2.0引入了一种新的缓存机制,它为我们的“鱼与熊掌兼得”带来了技术上的可行性。 .Net 2.0引入的自定义缓存依赖项,特别是基于MS-SQL Server的SqlCacheDependency特性,使得我们可以避免“数据过期”的问题,它能够根据数据库中相应数据的变化,通知缓存,并移除那些过期的数据。事实上,在PetShop 4.0中,就充分地利用了SqlCacheDependency特性。 4.2 SqlCacheDependency特性 SqlCacheDependency特性实际上是通过System.Web.Caching.SqlCacheDependency类来体现的。通过该类,可以在所有支持的SQL Server版本(7.0,2000,2005)上监视特定的SQL Server数据库表,并创建依赖于该表以及表中数据行的缓存项。当数据表或表中特定行的数据发生更改时,具有依赖项的数据项就会失效,并自动从Cache中删除该项,从而保证了缓存中不再保留过期的数据。 要使得7.0或者2000版本的SQL Server支持SqlCacheDependency特性,需要对数据库服务器执行相关的配置步骤。有两种方法配置SQL Server:使用aspnet_regsql命令行工具,或者使用SqlCacheDependencyAdmin类。 4.2.1 利用aspnet_regsql工具 aspnet_regsql工具位于Windows\Microsoft.NET\Framework\[版本]文件夹中。如果直接双击该工具的执行文件,会弹出一个向导对话框,提示我们完成相应的操作:
如图4-1所示中的提示信息,说明该向导主要用于配置SQL Server数据库,如membership,profiles等信息,如果要配置SqlCacheDependency,则需要以命令行的方式执行。以PetShop 4.0为例,数据库名为MSPetShop4,则命令为: 以下是该工具的命令参数说明: 以上面的命令为例,说明将对名为MSPetShop4的数据库采用SqlCacheDependency功能,且SQL Server采用了windows集成验证方式。我们还可以对相关的数据表执行aspnet_regsql命令,如: 当执行上述的四条命令后,aspnet_regsql工具会在MSPetShop4数据库中建立一个名为AspNet_SqlCacheTablesForChangeNotification的新数据库表。该数据表包含三个字段。字段tableName记录要追踪的数据表的名称,例如在PetShop 4.0中,要记录的数据表就包括Category、Item和Product。notificationCreated字段记录开始追踪的时间。changeId作为一个类型为int的字段,用于记录数据表数据发生变化的次数。如图4-2所示:
除此之外,执行该命令还会为MSPetShop4数据库添加一组存储过程,为ASP.NET提供查询追踪的数据表的情况,同时还将为使用了SqlCacheDependency的表添加触发器,分别对应Insert、Update、Delete等与数据更改相关的操作。例如Product数据表的触发器: 其中,AspNet_SqlCacheUpdateChangeIdStoredProcedure即是工具添加的一组存储过程中的一个。当对Product数据表执行Insert、Update或Delete等操作时,就会激活触发器,然后执行AspNet_SqlCacheUpdateChangeIdStoredProcedure存储过程。其执行的过程就是修改AspNet_SqlCacheTablesForChangeNotification数据表的changeId字段值: 4.2.2 利用SqlCacheDependencyAdmin类 我们也可以利用编程的方式来来管理数据库对SqlCacheDependency特性的使用。该类包含了五个重要的方法:
表4-1 SqlCacheDependencyAdmin类的主要方法 假设我们定义了如下的数据库连接字符串: 那么为数据库MSPetShop4启用SqlCacheDependency对象更改通知的实现为: 为数据表Product启用SqlCacheDependency对象更改通知的实现则为: 如果要调用表4-1中所示的相关方法,需要注意的是访问SQL Server数据库的帐户必须具有创建表和存储过程的权限。如果要调用EnableTableForNotifications方法,还需要具有在该表上创建SQL Server触发器的权限。 虽然说编程方式赋予了程序员更大的灵活性,但aspnet_regsql工具却提供了更简单的方法实现对SqlCacheDependency的配置与管理。PetShop 4.0采用的正是aspnet_regsql工具的办法,它编写了一个文件名为InstallDatabases.cmd的批处理文件,其中包含了对aspnet_regsql工具的执行,并通过安装程序去调用该文件,实现对SQL Server的配置。 4.3 在PetShop 4.0中ASP.NET缓存的实现 PetShop作为一个B2C的宠物网上商店,需要充分考虑访客的用户体验,如果因为数据量大而导致Web服务器的响应不及时,页面和查询数据迟迟得不到结果,会因此而破坏客户访问网站的心情,在耗尽耐心的等待后,可能会失去这一部分客户。无疑,这是非常糟糕的结果。因而在对其进行体系架构设计时,整个系统的性能就显得殊为重要。然而,我们不能因噎废食,因为专注于性能而忽略数据的正确性。在PetShop 3.0版本以及之前的版本,因为ASP.NET缓存的局限性,这一问题并没有得到很好的解决。PetShop 4.0则引入了SqlCacheDependency特性,使得系统对缓存的处理较之以前大为改观。 4.3.1 CacheDependency接口 PetShop 4.0引入了SqlCacheDependency特性,对Category、Product和Item数据表对应的缓存实施了SQL Cache Invalidation技术。当对应的数据表数据发生更改后,该技术能够将相关项从缓存中移除。实现这一技术的核心是SqlCacheDependency类,它继承了CacheDependency类。然而为了保证整个架构的可扩展性,我们也允许设计者建立自定义的CacheDependency类,用以扩展缓存依赖。这就有必要为CacheDependency建立抽象接口,并在web.config文件中进行配置。 在PetShop 4.0的命名空间PetShop.ICacheDependency中,定义了名为IPetShopCacheDependency接口,它仅包含了一个接口方法: AggregateCacheDependency是.Net Framework 2.0新增的一个类,它负责监视依赖项对象的集合。当这个集合中的任意一个依赖项对象发生改变时,该依赖项对象对应的缓存对象都将被自动移除。 4.3.2 CacheDependency实现 CacheDependency的实现正是为Category、Product和Item数据表建立了对应的SqlCacheDependency类型的依赖项,如代码所示: protected AggregateCacheDependency dependency = new AggregateCacheDependency(); foreach (string tableName in tables) 需要建立依赖项的数据库与数据表都配置在web.config文件中,其设置如下: 根据各个数据表间的依赖关系,因而不同的数据表需要建立的依赖项也是不相同的,从配置文件中的value值可以看出。然而不管建立依赖项的多寡,其创建的行为逻辑都是相似的,因而在设计时,抽象了一个共同的类TableDependency,并通过建立带参数的构造函数,完成对依赖项的建立。由于接口方法GetDependency()的实现中,返回的对象dependency是在受保护的构造函数创建的,因此这里的实现方式也可以看作是Template Method模式的灵活运用。例如TableDependency的子类Product,就是利用父类的构造函数建立了Product、Category数据表的SqlCacheDependency依赖: 如果需要自定义CacheDependency,那么创建依赖项的方式又有不同。然而不管是创建SqlCacheDependency对象,还是自定义的CacheDependency对象,都是将这些依赖项添加到AggregateCacheDependency类中,因而我们也可以为自定义CacheDependency建立专门的类,只要实现IPetShopCacheDependency接口即可。 4.3.3 CacheDependency工厂 继承了抽象类TableDependency的Product、Category和Item类均需要在调用时创建各自的对象。由于它们的父类TableDependency实现了接口IPetShopCacheDependency,因而它们也间接实现了IPetShopCacheDependency接口,这为实现工厂模式提供了前提。 在PetShop 4.0中,依然利用了配置文件和反射技术来实现工厂模式。命名空间PetShop.CacheDependencyFactory中,类DependencyAccess即为创建IPetShopCacheDependency对象的工厂类:
虽然DependencyAccess类创建了实现了IPetShopCacheDependency接口的类Category、Product、Item,然而我们之所以引入IPetShopCacheDependency接口,其目的就在于获得创建了依赖项的AggregateCacheDependency类型的对象。我们可以调用对象的接口方法GetDependency(),如下所示: 为了方便调用者,似乎我们可以对DependencyAccess类进行改进,将原有的CreateCategoryDependency()方法,修改为创建AggregateCacheDependency类型对象的方法。 然而这样的做法扰乱了作为工厂类的DependencyAccess的本身职责,且创建IPetShopCacheDependency接口对象的行为仍然有可能被调用者调用,所以保留原有的DependencyAccess类仍然是有必要的。 在PetShop 4.0的设计中,是通过引入Facade模式以方便调用者更加简单地获得AggregateCacheDependency类型对象。 4.3.4 引入Facade模式 利用Facade模式可以将一些复杂的逻辑进行包装,以方便调用者对这些复杂逻辑的调用。就好像提供一个统一的门面一般,将内部的子系统封装起来,统一为一个高层次的接口。一个典型的Facade模式示意图如下所示:
Facade模式的目的并非要引入一个新的功能,而是在现有功能的基础上提供一个更高层次的抽象,使得调用者可以直接调用,而不用关心内部的实现方式。以CacheDependency工厂为例,我们需要为调用者提供获得AggregateCacheDependency对象的简便方法,因而创建了DependencyFacade类: DependencyFacade类封装了获取AggregateCacheDependency类型对象的逻辑,如此一来,调用者可以调用相关方法获得创建相关依赖项的AggregateCacheDependency类型对象: 比起直接调用DependencyAccess类的GetDependency()方法而言,除了方法更简单之外,同时它还对CacheDependencyAssembly配置节进行了判断,如果其值为空,则返回null对象。 在PetShop.Web的App_Code文件夹下,静态类WebUtility的GetCategoryName()和GetProductName()方法调用了DependencyFacade类。例如GetCategoryName()方法: string cacheKey = string.Format(CATEGORY_NAME_KEY, categoryId); // 检查缓存中是否存在该数据项; GetCategoryName()方法首先会检查缓存中是否已经存在CategoryName数据项,如果已经存在,就通过缓存直接获取数据;否则将通过业务逻辑层调用数据访问层访问数据库获得CategoryName,在获得了CategoryName后,会将新获取的数据连同DependencyFacade类创建的AggregateCacheDependency对象添加到缓存中。 WebUtility静态类被表示层的许多页面所调用,例如Product页面: 显示页面title的逻辑是放在Page_Load事件方法中,因而每次打开该页面都要执行获取CategoryName的方法。如果没有采用缓存机制,当Category数据较多时,页面的显示就会非常缓慢。 4.3.5 引入Proxy模式 业务逻辑层BLL中与Product、Category、Item有关的业务方法,其实现逻辑是调用数据访问层(DAL)对象访问数据库,以获取相关数据。为了改善系统性能,我们就需要为这些实现方法增加缓存机制的逻辑。当我们操作增加了缓存机制的业务对象时,对于调用者而言,应与BLL业务对象的调用保持一致。也即是说,我们需要引入一个新的对象去控制原来的BLL业务对象,这个新的对象就是Proxy模式中的代理对象。 以PetShop.BLL.Product业务对象为例,PetShop为其建立了代理对象ProductDataProxy,并在GetProductByCategory()等方法中,引入了缓存机制,例如: private static readonly int productTimeout = int.Parse(ConfigurationManager.AppSettings[”ProductCacheDuration”]); if (!enableCaching) string key = “product_by_category_” + category; // Check if the data exists in the data cache // Create a AggregateCacheDependency object from the factory // Store the output in the data cache, and Add the necessary AggregateCacheDependency object 与业务逻辑层Product对象的GetProductsByCategory()方法相比,增加了缓存机制。当缓存内不存在相关数据项时,则直接调用业务逻辑层Product的GetProductsByCategory()方法来获取数据,并将其与对应的AggregateCacheDependency对象一起存储在缓存中。 引入Proxy模式,实现了在缓存级别上对业务对象的封装,增强了对业务对象的控制。由于暴露在对象外的方法是一致的,因而对于调用方而言,调用代理对象与真实对象并没有实质的区别。 从职责分离与分层设计的角度分析,我更希望这些Proxy对象是被定义在业务逻辑层中,而不像在PetShop的设计那样,被划分到表示层UI中。此外,如果需要考虑程序的可扩展性与可替换性,我们还可以为真实对象与代理对象建立统一的接口或抽象类。然而,单以PetShop的表示层调用来看,采用静态类与静态方法的方式,或许更为合理。我们需要谨记,“过度设计”是软件设计的警戒线。 如果需要对UI层采用缓存机制,将应用程序数据存放到缓存中,就可以调用这些代理对象。以ProductsControl用户控件为例,调用方式如下: productsList对象属于自定义的CustomList类型,这是一个派生自System.Web.UI.WebControls.DataList控件的类,它的DataSource属性可以接受IList集合对象。 与ASP.NET 1.x的页输出缓存不同的是,在ASP.NET 2.0中,为ASP.NET用户控件新引入了CachePolicy属性,该属性的类型为ControlCachePolicy类,它以编程方式实现了对ASP.NET用户控件的输出缓存设置。我们可以通过设置ControlCachePolicy类的Dependency属性,来设置与该用户控件相关的依赖项,例如在ProductsControl用户控件中,进行如下的设置: 采用页输出缓存,并且利用ControlCachePolicy设置输出缓存,能够将业务数据与整个页面放入到缓存中。这种方式比起应用程序缓存而言,在性能上有很大的提高。同时,它又通过引入的SqlCacheDependency特性有效地避免了“数据过期”的缺点,因而在PetShop 4.0中被广泛采用。相反,之前为Product、Category、Item业务对象建立的代理对象则被“投闲散置”,仅仅作为一种设计方法的展示而“幸存”与整个系统的源代码中。 PetShop之业务逻辑层设计Filed under: Design & Pattern — bruce zhang @ 4:11 pm
《解剖PetShop》系列之五 五 PetShop之业务逻辑层设计 业务逻辑层在体系架构中的位置很关键,它处于数据访问层与表示层中间,起到了数据交换中承上启下的作用。由于层是一种弱耦合结构,层与层之间的依赖是向下的,底层对于上层而言是“无知”的,改变上层的设计对于其调用的底层而言没有任何影响。如果在分层设计时,遵循了面向接口设计的思想,那么这种向下的依赖也应该是一种弱依赖关系。因而在不改变接口定义的前提下,理想的分层式架构,应该是一个支持可抽取、可替换的“抽屉”式架构。正因为如此,业务逻辑层的设计对于一个支持可扩展的架构尤为关键,因为它扮演了两个不同的角色。对于数据访问层而言,它是调用者;对于表示层而言,它却是被调用者。依赖与被依赖的关系都纠结在业务逻辑层上,如何实现依赖关系的解耦,则是除了实现业务逻辑之外留给设计师的任务。 5.1 与领域专家合作 领域专家在团队中扮演的角色通常称为Business Consultor(业务咨询师),负责提供与领域业务有关的咨询,与架构师一起参与架构与数据库的设计,撰写需求文档和设计用例(或者用户故事User Story)。如果在测试阶段,还应该包括撰写测试用例。理想的状态是,领域专家应该参与到整个项目的开发过程中,而不仅仅是需求阶段。 领域专家可以是专门聘请的对该领域具有较深造诣的咨询师,也可以是作为需求提供方的客户。在极限编程(Extreme Programming)中,就将客户作为领域专家引入到整个开发团队中。它强调了现场客户原则。现场客户需要参与到计划游戏、开发迭代、编码测试等项目开发的各个阶段。由于领域专家与设计师以及开发人员组成了一个团队,贯穿开发过程的始终,就可以避免需求理解错误的情况出现。即使项目的开发与实际需求不符,也可以在项目早期及时修正,从而避免了项目不必要的延期,加强了对项目过程和成本的控制。正如Steve McConnell在构建活动的前期准备中提及的一个原则:发现错误的时间要尽可能接近引入该错误的时间。需求的缺陷在系统中潜伏的时间越长,代价就越昂贵。如果在项目开发中能够与领域专家充分的合作,就可以最大效果地规避这样一种恶性的链式反应。 传统的软件开发模型同样重视与领域专家的合作,但这种合作主要集中在需求分析阶段。例如瀑布模型,就非常强调早期计划与需求调研。然而这种未雨绸缪的早期计划方式,对架构师与需求调研人员的技能要求非常高,它强调需求文档的精确性,一旦分析出现偏差,或者需求发生变更,当项目开发进入设计阶段后,由于缺乏与领域专家沟通与合作的机制,开发人员估量不到这些错误与误差,因而难以及时作出修正。一旦这些问题像毒瘤一般在系统中蔓延开来,逐渐暴露在开发人员面前时,已经成了一座难以逾越的高山。我们需要消耗更多的人力物力,才能够修正这些错误,从而导致开发成本成数量级的增加,甚至于导致项目延期。当然还有一个好的选择,就是放弃整个项目。这样的例子不胜枚举,事实上,项目开发的“滑铁卢”,究其原因,大部分都是因为业务逻辑分析上出现了问题。 迭代式模型较之瀑布模型有很大地改进,因为它允许变更、优化系统需求,整个迭代过程实际上就是与领域专家的合作过程,通过向客户演示迭代所产生的系统功能,从而及时获取反馈,并逐一解决迭代演示中出现的问题,保证系统向着合乎客户需求的方向演化。因而,迭代式模型往往能够解决早期计划不足的问题,它允许在发现缺陷的时候,在需求变更的时候重新设计、重新编码并重新测试。 无论采用何种开发模型,与领域专家的合作都将成为项目成败与否的关键。这基于一个软件开发的普遍真理,那就是世界上没有不变的需求。一句经典名言是:“没有不变的需求,世上的软件都改动过3次以上,唯一一个只改动过两次的软件的拥有者已经死了,死在去修改需求的路上。”一语道尽了软件开发的残酷与艰辛! 那么应该如何加强与领域专家的合作呢?James Carey和Brent Carlson根据他们在参与的IBM SanFrancisco项目中获得的经验,提出了Innocent Questions模式,其意义即“改进领域专家和技术专家的沟通质量”。在一个项目团队中,如果我们没有一位既能担任首席架构师,同时又是领域专家的人选,那么加强领域专家与技术专家的合作就显得尤为重要了。毕竟,作为一个领域专家而言,可能并不熟悉软件设计方法学,也不具备面向对象开发和架构设计的能力,同样,大部分技术专家很有可能对该项目所涉及的业务领域仅停留在一知半解的地步。如果领域专家与技术专家不能有效沟通,则整个项目的前途就岌岌可危了。 Innocent Questions模式提出的解决方案包括: 事实上,这已经从技术的角度上升到对团队的管理层次了。就好比篮球运动一样,即使你的球队集合了五名世界上最顶尖最有天赋的球员,如果各自为战,要想取得比赛的胜利依旧是非常困难的。团队精神与权责分明才是取得胜利的保障,软件开发同样如此。 与领域专家合作的基础是保证开发团队中永远保留至少一名领域专家。他可以是系统的客户,第三方公司的咨询师,最理想是自己公司雇佣的专家。如果项目中缺乏这样的一个人,那么我的建议是去雇佣他,如果你不想看到项目遭遇“西伯利亚寒流”的话。 确定领域专家的角色任务与职责。必须要让团队中的每一个人明确领域专家在整个团队中究竟扮演什么样的角色,他的职责是什么。一个合格的领域专家必须对业务领域有足够深入的理解,他应该是一个能够俯瞰整个系统需求、总揽全局的人物。在项目开发过程中,将由他负责业务规则和流程的制定,负责与客户的沟通,需求的调研与讨论,并于设计师一起参与系统架构的设计。编档是领域专家必须参与的工作,无论是需求文档还是设计文档,以及用例的编写,领域专家或者提出意见,或者作为撰写的作者,至少他也应该是评审委员会的重要成员。 规范业务领域的术语和技术术语。领域专家和技术专家必须在保证不产生二义性的语义环境下进行沟通与交流。如果出现理解上的分歧,我们必须及时解决,通过讨论确立术语标准。很难想象两个语言不通的人能够相互合作愉快,解决的办法是加入一位翻译人员。在领域专家与技术专家之间搭建一座语义上的桥梁,使其能够相互理解、相互认同。还有一个办法是在团队内部开展培训活动。尤其对于开发人员而言,或多或少地了解一些业务领域知识,对于项目的开发有很大的帮助。在我参与过的半导体领域的项目开发,团队就专门邀请了半导体行业的专家就生产过程的业务逻辑进行了全方位的介绍与培训。正所谓“磨刀不误砍柴工”,虽然我们消费了培训的时间,但对于掌握了业务规则与流程的开发人员,却能够提升项目开发进度,总体上节约了开发成本。 加强与客户的沟通。客户同时也可以作为团队的领域专家,极限编程的现场客户原则是最好的示例。但现实并不都如此的完美,在无法要求客户成为开发团队中的固定一员时,聘请或者安排一个专门的领域专家,加强与客户的沟通,就显得尤为重要。项目可以通过领域专家获得客户的及时反馈。而通过领域专家去了解变更了的需求,会在最大程度上减少需求误差的可能。 5.2 业务逻辑层的模式应用 Transaction Script模式将业务逻辑看作是一个个过程,是比较典型的面向过程开发模式。应用Transaction Script模式可以不需要数据访问层,而是利用SQL语句直接访问数据库。为了有效地管理SQL语句,可以将与数据库访问有关的行为放到一个专门的Gateway类中。应用Transaction Script模式不需要太多面向对象知识,简单直接的特性是该模式全部价值之所在。因而,在许多业务逻辑相对简单的项目中,应用Transaction Script模式较多。 Domain Model模式是典型的面向对象设计思想的体现。它充分考虑了业务逻辑的复杂多变,引入了Strategy模式等设计模式思想,并通过建立领域对象以及抽象接口,实现模式的可扩展性,并利用面向对象思想与身俱来的特性,如继承、封装与多态,用于处理复杂多变的业务逻辑。唯一制约该模式应用的是对象与关系数据库的映射。我们可以引入ORM工具,或者利用Data Mapper模式来完成关系向对象的映射。 与Domain Model模式相似的是Table Module模式,它同样具有面向对象设计的思想,唯一不同的是它获得的对象并非是单纯的领域对象,而是DataSet对象。如果为关系数据表与对象建立一个简单的映射关系,那么Domain Model模式就是为数据表中的每一条记录建立一个领域对象,而Table Module模式则是将整个数据表看作是一个完整的对象。虽然利用DataSet对象会丢失面向对象的基本特性,但它在为表示层提供数据源支持方面却有着得天独厚的优势。尤其是在.Net平台下,ADO.NET与Web控件都为Table Module模式提供了生长的肥沃土壤。 5.3 PetShop的业务逻辑层设计 本应是系统架构设计中最核心的业务逻辑层,由于简化了业务流程的缘故,使得PetShop在这一层的设计有些乏善可陈。虽然在业务逻辑层中,针对B2C业务定义了相关的领域对象,但这些领域对象仅仅是完成了对数据访问层中数据对象的简单封装而已,其目的仅在于分离层次,以支持对各种数据库的扩展,同时将SQL语句排除在业务逻辑层外,避免了SQL语句的四处蔓延。 最能体现PetShop业务逻辑的除了对订单的管理之外,还包括购物车(Shopping Cart)与Wish List的管理。在PetShop的BLL模块中,定义了Cart类来负责相关的业务逻辑,定义如下: Cart类通过一个Dictionary对象来负责对购物车内容的存储,同时定义了Add、Remove、Clear等方法,来实现对购物车内容的管理。 在前面我提到PetShop业务逻辑层中的领域对象仅仅是完成对数据对象的简单封装,但这种分离层次的方法在架构设计中依然扮演了举足轻重的作用。以Cart类的Add()方法为例,在方法内部引入了PetShop.BLL.Item领域对象,并调用了Item对象的GetItem()方法。如果没有在业务逻辑层封装Item对象,而是直接调用数据访问层的Item数据对象,为保证层次间的弱依赖关系,就需要调用工厂对象的工厂方法来创建PetShop.IDAL.IItem接口类型对象。一旦数据访问层的Item对象被多次调用,就会造成重复代码,既不离于程序的修改与扩展,也导致程序结构生长为臃肿的态势。 此外,领域对象对数据访问层数据对象的封装,也有利于表示层对业务逻辑层的调用。在三层式架构中,表示层应该是对于数据访问层是“无知”的,这样既减少了层与层间的依赖关系,也能有效避免“循环依赖”的后果。 值得商榷的是Cart类的Total属性。其值的获取是通过遍历购物车集合,然后累加价格与商品数量的乘积。这里显然简化了业务逻辑,而没有充分考虑需求的扩展。事实上,这种获取购物车总价格的算法,在大多数情况下仅仅是其中的一种策略而已,我们还应该考虑折扣的情况。例如,当总价格超过100元时,可以给与顾客一定的折扣,这是与网站的促销计划相关的。除了给与折扣的促销计划外,网站也可以考虑赠送礼品的促销策略,因此我们有必要引入Strategy模式,定义接口IOnSaleStrategy: 如此一来,我们可以为Cart类定义一个有参数的构造函数: 那么Total属性就可以修改为: 如此一来,就可以使得Cart类能够有效地支持网站推出的促销计划,也符合开-闭原则。同样的,这种设计方式也是Domain Model模式的体现。修改后的设计如图5-1所示:
图5-1 引入Strategy模式 作为一个B2C的电子商务架构,它所涉及的业务领域已为大部分设计师与开发人员所熟悉,因而在本例中,与领域专家的合作显得并不那么重要。然而,如果我们要开发一个成功的电子商务网站,与领域专家的合作仍然是必不可少的。以订单的管理而言,如果考虑复杂的商业应用,就需要管理订单的跟踪(Tracking),与网上银行的合作,账户安全性,库存管理,物流管理,以及客户关系管理(CRM)。整个业务过程却涵盖了诸如电子商务、银行、物流、客户关系学等诸多领域,如果没有领域专家的参与,业务逻辑层的设计也许会“败走麦城”。 5.4 与数据访问层的通信 // 通过数据访问层的数据对象访问数据库; 在领域对象Product类中,利用数据访问层的工厂类DALFactory.DataAccess创建PetShop.IDAL.IProduct类型的实例,如此就可以解除对具体程序集SQLServerDAL或OracleDAL的依赖。只要PetShop.IDAL的接口方法不变,即使修改了IDAL接口模块的具体实现,都不会影响业务逻辑层的实现。这种松散的弱耦合关系,才能够最大程度地支持架构的可扩展。 领域对象Product实际上还完成了对数据对象Product的封装,它们暴露在外的接口方法是一致地,正是通过封装,使得表示层可以完全脱离数据库以及数据访问层,表示层的调用者仅需要关注业务逻辑层的实现逻辑,以及领域对象暴露的接口和调用方式。事实上,只要设计合理,规范了各个层次的接口方法,三层式架构的设计完全可以分离开由不同的开发人员同时开发,这就可以有效地利用开发资源,缩短项目开发周期。 5.5 面向接口设计 然而,最理想的方式仍然是面向接口设计。根据第28章对ASP.NET缓存的分析,我们可以将表示层App_Code下的Proxy类与Utility类划分到业务逻辑层中,并修改这些静态类为实例类,并将这些类中与业务领域有关的方法抽象为接口,然后建立如数据访问层一样的抽象工厂。通过“依赖注入”方式,解除与具体领域对象类的依赖,使得表示层仅依赖于业务逻辑层的接口程序集以及工厂模块。 那么,这样的设计是否有“过度设计”的嫌疑呢?我们需要依据业务逻辑的需求情况而定。此外,如果我们需要引入缓存机制,为领域对象创建代理类,那么为领域对象建立接口,就显得尤为必要。我们可以建立一个专门的接口模块IBLL,用以定义领域对象的接口。以Product领域对象为例,我们可以建立IProduct接口: 在BLL模块中可以引入对IBLL程序集的依赖,则领域对象Product的定义如下: 然后我们可以为代理对象建立专门的程序集BLLProxy,它不仅引入对IBLL程序集的依赖,同时还将依赖于BLL程序集。此时代理对象ProductDataProxy的定义如下: 如此的设计正是典型的Proxy模式,其类结构如图5-2所示:
图5-2 Proxy模式 参照数据访问层的设计方法,我们可以为领域对象及代理对象建立抽象工厂,并在web.config中配置相关的配置节,然后利用反射技术创建具体的对象实例。如此一来,表示层就可以仅仅依赖PetShop.IBLL程序集以及工厂模块,如此就可以解除表示层与具体领域对象之间的依赖关系。表示层与修改后的业务逻辑层的关系如图5-3所示:
图5-3 修改后的业务逻辑层与表示层的关系 图5-4则是PetShop 4.0原有设计的层次关系图:
图5-4 PetShop 4.0中表示层与业务逻辑层的关系 通过比较图5-3与图5-4,虽然后者不管是模块的个数,还是模块之间的关系,都相对更加简单,然而Web Component组件与业务逻辑层之间却是强耦合的,这样的设计不利于应对业务扩展与需求变更。通过引入接口模块IBLL与工厂模块BLLFactory,解除了与具体模块BLL的依赖关系。这种设计对于业务逻辑相对比较复杂的系统而言,更符合面向对象的设计思想,有利于我们建立可抽取、可替换的“抽屉”式三层架构。 ASP.NET
asp.net程序中最常用的三十三种编程代码 1. 打开新的窗口并传送参数: 传送参数: response.write("<script>window.open(’*.aspx?id="+this.DropDownList1.SelectIndex+"&id1="+...+"’)</script>") 接收参数: string a = Request.QueryString("id"); string b = Request.QueryString("id1"); 2.为按钮添加对话框 Button1.Attributes.Add("onclick","return confirm(’确认?’)"); button.attributes.add("onclick","if(confirm(’are you sure...?’)){return true;}else{return false;}") 3.删除表格选定记录 int intEmpID = (int)MyDataGrid.DataKeys[e.Item.ItemIndex]; string deleteCmd = "DELETE from Employee where emp_id = " + intEmpID.ToString() 4.删除表格记录警告 private void DataGrid_ItemCreated(Object sender,DataGridItemEventArgs e) { switch(e.Item.ItemType) { case ListItemType.Item : case ListItemType.AlternatingItem : case ListItemType.EditItem: TableCell myTableCell; myTableCell = e.Item.Cells[14]; LinkButton myDeleteButton ; myDeleteButton = (LinkButton)myTableCell.Controls[0]; myDeleteButton.Attributes.Add("onclick","return confirm(’您是否确定要删除这条信息’);"); break; default: break; } } 5.点击表格行链接另一页 private void grdCustomer_ItemDataBound(object sender, System.Web.UI.WebControls.DataGridItemEventArgs e) { //点击表格打开 if (e.Item.ItemType == ListItemType.Item || e.Item.ItemType == ListItemType.AlternatingItem) e.Item.Attributes.Add("onclick","window.open(’Default.aspx?id=" + e.Item.Cells[0].Text + "’);"); } 双击表格连接到另一页 在itemDataBind事件中 if(e.Item.ItemType == ListItemType.Item || e.Item.ItemType == ListItemType.AlternatingItem) { string OrderItemID =e.item.cells[1].Text; ... e.item.Attributes.Add("ondblclick", "location.href=’../ShippedGrid.aspx?id=" + OrderItemID + "’"); } 双击表格打开新一页 if(e.Item.ItemType == ListItemType.Item || e.Item.ItemType == ListItemType.AlternatingItem) { string OrderItemID =e.item.cells[1].Text; ... e.item.Attributes.Add("ondblclick", "open(’../ShippedGrid.aspx?id=" + OrderItemID + "’)"); } ★特别注意:【?id=】 处不能为 【?id =】 6.表格超连接列传递参数 <asp:HyperLinkColumn Target="_blank" headertext="ID号" DataTextField="id" NavigateUrl="aaa.aspx?id=’ <%# DataBinder.Eval(Container.DataItem, "数据字段1")%>’ & name=’<%# DataBinder.Eval(Container.DataItem, "数据字段2")%>’ /> 7.表格点击改变颜色 if (e.Item.ItemType == ListItemType.Item ||e.Item.ItemType == ListItemType.AlternatingItem) { e.Item.Attributes.Add("onclick","this.style.backgroundColor=’#99cc00’; this.style.color=’buttontext’;this.style.cursor=’default’;"); } 写在DataGrid的_ItemDataBound里 if (e.Item.ItemType == ListItemType.Item ||e.Item.ItemType == ListItemType.AlternatingItem) { e.Item.Attributes.Add("onmouseover","this.style.backgroundColor=’#99cc00’; this.style.color=’buttontext’;this.style.cursor=’default’;"); e.Item.Attributes.Add("onmouseout","this.style.backgroundColor=’’;this.style.color=’’;"); } 8.关于日期格式 日期格式设定 DataFormatString="{0:yyyy-MM-dd}" 我觉得应该在itembound事件中 e.items.cell["你的列"].text=DateTime.Parse(e.items.cell["你的列"].text.ToString("yyyy-MM-dd")) 9.获取错误信息并到指定页面 不要使用Response.Redirect,而应该使用Server.Transfer e.g // in global.asax protected void Application_Error(Object sender, EventArgs e) { if (Server.GetLastError() is HttpUnhandledException) Server.Transfer("MyErrorPage.aspx"); //其余的非HttpUnhandledException异常交给ASP.NET自己处理就okay了 :) } Redirect会导致post-back的产生从而丢失了错误信息,所以页面导向应该直接在服务器端执行,这样就可以在错误处理页面得到出错信息并进行相应的处理 10.清空Cookie Cookie.Expires=[DateTime]; Response.Cookies("UserName").Expires = 0 11.自定义异常处理 //自定义异常处理类 using System; using System.Diagnostics; namespace MyAppException { /// <summary> /// 从系统异常类ApplicationException继承的应用程序异常处理类。 /// 自动将异常内容记录到Windows NT/2000的应用程序日志 /// </summary> public class AppException:System.ApplicationException { public AppException() { if (ApplicationConfiguration.EventLogEnabled)LogEvent("出现一个未知错误。"); } public AppException(string message) { LogEvent(message); } public AppException(string message,Exception innerException) { LogEvent(message); if (innerException != null) { LogEvent(innerException.Message); } } //日志记录类 using System; using System.Configuration; using System.Diagnostics; using System.IO; using System.Text; using System.Threading; namespace MyEventLog { /// <summary> /// 事件日志记录类,提供事件日志记录支持 /// <remarks> /// 定义了4个日志记录方法 (error, warning, info, trace) /// </remarks> /// </summary> public class ApplicationLog { /// <summary> /// 将错误信息记录到Win2000/NT事件日志中 /// <param name="message">需要记录的文本信息</param> /// </summary> public static void WriteError(String message) { WriteLog(TraceLevel.Error, message); } /// <summary> /// 将警告信息记录到Win2000/NT事件日志中 /// <param name="message">需要记录的文本信息</param> /// </summary> public static void WriteWarning(String message) { WriteLog(TraceLevel.Warning, message); } /// <summary> /// 将提示信息记录到Win2000/NT事件日志中 /// <param name="message">需要记录的文本信息</param> /// </summary> public static void WriteInfo(String message) { WriteLog(TraceLevel.Info, message); } /// <summary> /// 将跟踪信息记录到Win2000/NT事件日志中 /// <param name="message">需要记录的文本信息</param> /// </summary> public static void WriteTrace(String message) { WriteLog(TraceLevel.Verbose, message); } /// <summary> /// 格式化记录到事件日志的文本信息格式 /// <param name="ex">需要格式化的异常对象</param> /// <param name="catchInfo">异常信息标题字符串.</param> /// <retvalue> /// <para>格式后的异常信息字符串,包括异常内容和跟踪堆栈.</para> /// </retvalue> /// </summary> public static String FormatException(Exception ex, String catchInfo) { StringBuilder strBuilder = new StringBuilder(); if (catchInfo != String.Empty) { strBuilder.Append(catchInfo).Append("\r\n"); } strBuilder.Append(ex.Message).Append("\r\n").Append(ex.StackTrace); return strBuilder.ToString(); } /// <summary> /// 实际事件日志写入方法 /// <param name="level">要记录信息的级别(error,warning,info,trace).</param> /// <param name="messageText">要记录的文本.</param> /// </summary> private static void WriteLog(TraceLevel level, String messageText) { try { EventLogEntryType LogEntryType; switch (level) { case TraceLevel.Error: LogEntryType = EventLogEntryType.Error; break; case TraceLevel.Warning: LogEntryType = EventLogEntryType.Warning; break; case TraceLevel.Info: LogEntryType = EventLogEntryType.Information; break; case TraceLevel.Verbose: LogEntryType = EventLogEntryType.SuccessAudit; break; default: LogEntryType = EventLogEntryType.SuccessAudit; break; } EventLog eventLog = new EventLog("Application", ApplicationConfiguration.EventLogMachineName, ApplicationConfiguration.EventLogSourceName ); //写入事件日志 eventLog.WriteEntry(messageText, LogEntryType); } catch {} //忽略任何异常 } } //class ApplicationLog } 12.Panel 横向滚动,纵向自动扩展 <asp:panel style="overflow-x:scroll;overflow-y:auto;"></asp:panel> 13.回车转换成Tab <script language="javascript" for="document" event="onkeydown"> if(event.keyCode==13 && event.srcElement.type!=’button’ && event.srcElement.type!=’submit’ && event.srcElement.type!=’reset’ && event.srcElement.type!=’’&& event.srcElement.type!=’textarea’); event.keyCode=9; </script> onkeydown="if(event.keyCode==13) event.keyCode=9" 14.DataGrid超级连接列 DataNavigateUrlField="字段名" DataNavigateUrlFormatString="http://xx/inc/delete.aspx?ID={0}" 15.DataGrid行随鼠标变色 private void DGzf_ItemDataBound(object sender, System.Web.UI.WebControls.DataGridItemEventArgs e) { if (e.Item.ItemType!=ListItemType.Header) { e.Item.Attributes.Add( "onmouseout","this.style.backgroundColor=\""+e.Item.Style["BACKGROUND-COLOR"]+"\""); e.Item.Attributes.Add( "onmouseover","this.style.backgroundColor=\""+ "#EFF3F7"+"\""); } } 16.模板列 <ASP:TEMPLATECOLUMN visible="False" sortexpression="demo" headertext="ID"> <ITEMTEMPLATE> <ASP:LABEL text=’<%# DataBinder.Eval(Container.DataItem, "ArticleID")%>’ runat="server" width="80%" id="lblColumn" /> </ITEMTEMPLATE> </ASP:TEMPLATECOLUMN> <ASP:TEMPLATECOLUMN headertext="选中"> <HEADERSTYLE wrap="False" horizontalalign="Center"></HEADERSTYLE> <ITEMTEMPLATE> <ASP:CHECKBOX id="chkExport" runat="server" /> </ITEMTEMPLATE> <EDITITEMTEMPLATE> <ASP:CHECKBOX id="chkExportON" runat="server" enabled="true" /> </EDITITEMTEMPLATE> </ASP:TEMPLATECOLUMN> 后台代码 protected void CheckAll_CheckedChanged(object sender, System.EventArgs e) { //改变列的选定,实现全选或全不选。 CheckBox chkExport ; if( CheckAll.Checked) { foreach(DataGridItem oDataGridItem in MyDataGrid.Items) { chkExport = (CheckBox)oDataGridItem.FindControl("chkExport"); chkExport.Checked = true; } } else { foreach(DataGridItem oDataGridItem in MyDataGrid.Items) { chkExport = (CheckBox)oDataGridItem.FindControl("chkExport"); chkExport.Checked = false; } } } 17.数字格式化 【<%#Container.DataItem("price")%>的结果是500.0000,怎样格式化为500.00?】 <%#Container.DataItem("price","{0:¥#,##0.00}")%> int i=123456; string s=i.ToString("###,###.00"); 18.日期格式化 【aspx页面内:<%# DataBinder.Eval(Container.DataItem,"Company_Ureg_Date")%> 显示为: 2004-8-11 19:44:28 我只想要:2004-8-11 】 <%# DataBinder.Eval(Container.DataItem,"Company_Ureg_Date","{0:yyyy-M-d}")%> 应该如何改? 【格式化日期】 取出来,一般是object((DateTime)objectFromDB).ToString("yyyy-MM-dd"); 【日期的验证表达式】 A.以下正确的输入格式: [2004-2-29], [2004-02-29 10:29:39 pm], [2004/12/31] ^((\d{2}(([02468][048])|([13579][26]))[\-\/\s]?((((0?[13578])|(1[02]))[\-\/\s]?((0?[1-9])|([1-2][0-9])|(3[01])))|(((0?[469])|(11))[\-\/\s]?((0?[1-9])|([1-2][0-9])|(30)))|(0?2[\-\/\s]?((0?[1-9])|([1-2][0-9])))))|(\d{2}(([02468][1235679])|([13579][01345789]))[\-\/\s]?((((0?[13578])|(1[02]))[\-\/\s]?((0?[1-9])|([1-2][0-9])|(3[01])))|(((0?[469])|(11))[\-\/\s]?((0?[1-9])|([1-2][0-9])|(30)))|(0?2[\-\/\s]?((0?[1-9])|(1[0-9])|(2[0-8]))))))(\s(((0?[1-9])|(1[0-2]))\:([0-5][0-9])((\s)|(\:([0-5][0-9])\s))([AM|PM|am|pm]{2,2})))?$ B.以下正确的输入格式:[0001-12-31], [9999 09 30], [2002/03/03] ^\d{4}[\-\/\s]?((((0[13578])|(1[02]))[\-\/\s]?(([0-2][0-9])|(3[01])))|(((0[469])|(11))[\-\/\s]?(([0-2][0-9])|(30)))|(02[\-\/\s]?[0-2][0-9]))$ 【大小写转换】 HttpUtility.HtmlEncode(string); HttpUtility.HtmlDecode(string) 19.如何设定全局变量 Global.asax中 Application_Start()事件中 添加Application[属性名] = xxx; 就是你的全局变量 20.怎样作到HyperLinkColumn生成的连接后,点击连接,打开新窗口? HyperLinkColumn有个属性Target,将器值设置成"_blank"即可.(Target="_blank") 【ASPNETMENU】点击菜单项弹出新窗口 在你的menuData.xml文件的菜单项中加入URLTarget="_blank",如: <?xml version="1.0" encoding="GB2312"?> <MenuData ImagesBaseURL="images/"> <MenuGroup> <MenuItem Label="内参信息" URL="Infomation.aspx" > <MenuGroup ID="BBC"> <MenuItem Label="公告信息" URL="Infomation.aspx" URLTarget="_blank" LeftIcon="file.gif"/> <MenuItem Label="编制信息简报" URL="NewInfo.aspx" LeftIcon="file.gif" /> ...... 最好将你的aspnetmenu升级到1.2版 21.读取DataGrid控件TextBox值 foreach(DataGrid dgi in yourDataGrid.Items) { TextBox tb = (TextBox)dgi.FindControl("yourTextBoxId"); tb.Text.... } 23.在DataGrid中有3个模板列包含Textbox分别为 DG_ShuLiang (数量) DG_DanJian(单价) DG_JinE(金额)分别在5.6.7列,要求在录入数量及单价的时候自动算出金额即:数量*单价=金额还要求录入时限制为 数值型.我如何用客户端脚本实现这个功能? 〖思归〗 <asp:TemplateColumn HeaderText="数量"> <ItemTemplate> <asp:TextBox id="ShuLiang" runat=’server’ Text=’<%# DataBinder.Eval(Container.DataItem,"DG_ShuLiang")%>’ onkeyup="javascript:DoCal()" /> <asp:RegularExpressionValidator id="revS" runat="server" ControlToValidate="ShuLiang" ErrorMessage="must be integer" ValidationExpression="^\d+$" /> </ItemTemplate> </asp:TemplateColumn> <asp:TemplateColumn HeaderText="单价"> <ItemTemplate> <asp:TextBox id="DanJian" runat=’server’ Text=’<%# DataBinder.Eval(Container.DataItem,"DG_DanJian")%>’ onkeyup="javascript:DoCal()" /> <asp:RegularExpressionValidator id="revS2" runat="server" ControlToValidate="DanJian" ErrorMessage="must be numeric" ValidationExpression="^\d+(\.\d*)?$" /> </ItemTemplate> </asp:TemplateColumn> <asp:TemplateColumn HeaderText="金额"> <ItemTemplate> <asp:TextBox id="JinE" runat=’server’ Text=’<%# DataBinder.Eval(Container.DataItem,"DG_JinE")%>’ /> </ItemTemplate> </asp:TemplateColumn><script language="javascript"> function DoCal() { var e = event.srcElement; var row = e.parentNode.parentNode; var txts = row.all.tags("INPUT"); if (!txts.length || txts.length < 3) return; var q = txts[txts.length-3].value; var p = txts[txts.length-2].value; if (isNaN(q) || isNaN(p)) return; q = parseInt(q); p = parseFloat(p); txts[txts.length-1].value = (q * p).toFixed(2); } </script> 24.datagrid选定比较底下的行时,为什么总是刷新一下,然后就滚动到了最上面,刚才选定的行因屏幕的关系就看不到了。 page_load page.smartNavigation=true 25.在Datagrid中修改数据,当点击编辑键时,数据出现在文本框中,怎么控制文本框的大小 ? private void DataGrid1_ItemDataBound(obj sender,DataGridItemEventArgs e) { for(int i=0;i<e.Item.Cells.Count-1;i++) if(e.Item.ItemType==ListItemType.EditType) { e.Item.Cells[i].Attributes.Add("Width", "80px") } } 26.对话框 private static string ScriptBegin = "<script language=\"JavaScript\">"; private static string ScriptEnd = "</script>"; public static void ConfirmMessageBox(string PageTarget,string Content) { string ConfirmContent="var retValue=window.confirm(’"+Content+"’);"+"if(retValue){window.location=’"+PageTarget+"’;}"; ConfirmContent=ScriptBegin + ConfirmContent + ScriptEnd; Page ParameterPage = (Page)System.Web.HttpContext.Current.Handler; ParameterPage.RegisterStartupScript("confirm",ConfirmContent); //Response.Write(strScript); } 27. 将时间格式化:string aa=DateTime.Now.ToString("yyyy年MM月dd日"); 1.1 取当前年月日时分秒 currentTime=System.DateTime.Now; 1.2 取当前年 int 年= DateTime.Now.Year; 1.3 取当前月 int 月= DateTime.Now.Month; 1.4 取当前日 int 日= DateTime.Now.Day; 1.5 取当前时 int 时= DateTime.Now.Hour; 1.6 取当前分 int 分= DateTime.Now.Minute; 1.7 取当前秒 int 秒= DateTime.Now.Second; 1.8 取当前毫秒 int 毫秒= DateTime.Now.Millisecond; 28.自定义分页代码: 先定义变量 : public static int pageCount; //总页面数 public static int curPageIndex=1; //当前页面 下一页: if(DataGrid1.CurrentPageIndex < (DataGrid1.PageCount - 1)) { DataGrid1.CurrentPageIndex += 1; curPageIndex+=1; } bind(); // DataGrid1数据绑定函数 上一页: if(DataGrid1.CurrentPageIndex >0) { DataGrid1.CurrentPageIndex += 1; curPageIndex-=1; } bind(); // DataGrid1数据绑定函数 直接页面跳转: int a=int.Parse(JumpPage.Value.Trim());//JumpPage.Value.Trim()为跳转值 if(a<DataGrid1.PageCount) { this.DataGrid1.CurrentPageIndex=a; } bind(); 29.DataGrid使用: 添加删除确认: private void DataGrid1_ItemCreated(object sender, System.Web.UI.WebControls.DataGridItemEventArgs e) { foreach(DataGridItem di in this.DataGrid1.Items) { if(di.ItemType==ListItemType.Item||di.ItemType==ListItemType.AlternatingItem) { ((LinkButton)di.Cells[8].Controls[0]).Attributes.Add("onclick","return confirm(’确认删除此项吗?’);"); } } } 样式交替: ListItemType itemType = e.Item.ItemType; if (itemType == ListItemType.Item ) { e.Item.Attributes["onmouseout"] = "javascript:this.style.backgroundColor=’#FFFFFF’;"; e.Item.Attributes["onmouseover"] = "javascript:this.style.backgroundColor=’#d9ece1’;cursor=’hand’;" ; } else if( itemType == ListItemType.AlternatingItem) { e.Item.Attributes["onmouseout"] = "javascript:this.style.backgroundColor=’#a0d7c4’;"; e.Item.Attributes["onmouseover"] = "javascript:this.style.backgroundColor=’#d9ece1’;cursor=’hand’;" ; } 添加一个编号列: DataTable dt= c.ExecuteRtnTableForAccess(sqltxt); //执行sql返回的DataTable DataColumn dc=dt.Columns.Add("number",System.Type.GetType("System.String")); for(int i=0;i<dt.Rows.Count;i++) { dt.Rows[i]["number"]=(i+1).ToString(); } DataGrid1.DataSource=dt; DataGrid1.DataBind(); DataGrid1中添加一个CheckBox,页面中添加一个全选框 private void CheckBox2_CheckedChanged(object sender, System.EventArgs e) { foreach(DataGridItem thisitem in DataGrid1.Items) { ((CheckBox)thisitem.Cells[0].Controls[1]).Checked=CheckBox2.Checked; } } 将当前页面中DataGrid1显示的数据全部删除 foreach(DataGridItem thisitem in DataGrid1.Items) { if(((CheckBox)thisitem.Cells[0].Controls[1]).Checked) { string strloginid= DataGrid1.DataKeys[thisitem.ItemIndex].ToString(); Del (strloginid); //删除函数 } } 30.当文件在不同目录下,需要获取数据库连接字符串(如果连接字符串放在Web.config,然后在Global.asax中初始化) 在Application_Start中添加以下代码: Application["ConnStr"]=this.Context.Request.PhysicalApplicationPath+ConfigurationSettings. AppSettings["ConnStr"].ToString(); 31. 变量.ToString() 字符型转换 转为字符串 12345.ToString("n"); //生成 12,345.00 12345.ToString("C"); //生成 ¥12,345.00 12345.ToString("e"); //生成 1.234500e+004 12345.ToString("f4"); //生成 12345.0000 12345.ToString("x"); //生成 3039 (16进制) 12345.ToString("p"); //生成 1,234,500.00% 32、变量.Substring(参数1,参数2); 截取字串的一部分,参数1为左起始位数,参数2为截取几位。 如:string s1 = str.Substring(0,2); 33.在自己的网站上登陆其他网站:(如果你的页面是通过嵌套方式的话,因为一个页面只能有一个FORM,这时可以导向另外一个页面再提交登陆信息) <SCRIPT language="javascript"> <!-- function gook(pws) { frm.submit(); } //--> </SCRIPT> <body leftMargin="0" topMargin="0" onload="javascript:gook()" marginwidth="0" marginheight="0"> <form name="frm" action=" http://220.194.55.68:6080/login.php?retid=7259 " method="post"> <tr> <td> <input id="f_user" type="hidden" size="1" name="f_user" runat="server"> <input id="f_domain" type="hidden" size="1" name="f_domain" runat="server"> <input class="box" id="f_pass" type="hidden" size="1" name="pwshow" runat="server"> <INPUT id="lng" type="hidden" maxLength="20" size="1" value="5" name="lng"> <INPUT id="tem" type="hidden" size="1" value="2" name="tem"> </td> </tr> </form> 文本框的名称必须是你要登陆的网页上的名称,如果源码不行可以用vsniffer 看看。 下面是获取用户输入的登陆信息的代码: string name; name=Request.QueryString["EmailName"]; try { int a=name.IndexOf("@",0,name.Length); f_user.Value=name.Substring(0,a); f_domain.Value=name.Substring(a+1,name.Length-(a+1)); f_pass.Value=Request.QueryString["Psw"]; } catch { Script.Alert("错误的邮箱!"); Server.Transfer("index.aspx"); } DataGrid 通过DataSource 和 DataMember 属性来绑定其要显示的数据源。数据源一般是DataTable、DataView、DataSet等,不过将这些数据源绑定到DataGrid时实际上是绑定的DataView。 一、DataTable DataTable表示内存中数据的一个表,它完全是在内存中的一个独立存在,包含了这张表的全部信息。DataTable可以是从通过连接从数据库中读取出来形成的一个表,一旦将内容读到DataTable中,此DataTable就可以跟数据源断开而独立存在;也可以是完全由程序自己通过代码来建立的一个表。 ◆ DataColumn 一个表是由行和列组成的一个两维的结构。表的结构是由 DataColumn 对象的集合组成,DataColumn 对象集合可由DataTable.Columns 属性中能获取到,通过定义每一列的数据类型来确定表的架构,类似数据库中定义表。定义完表的结构就可以根据结构来生成DataRow,用 DataTable.NewRow()方法来生成此DataTable结构的新行。 一个DataTable是由DataRow的集合组成的, DataRow的集合这个可以由DataTable.Rows 属性来访问。 DataTable还可以通过现有的列用Expression 属性的表达式创建一些列。 1、创建计算出的列 比如:已经有了一个表结构,表中有一个DataColumn的集合,其中有一个叫UnitPrice的列,你可以新建一个 DataColumn,设置好ColumnName,再设置此列的表达式,DataColumn.Expression = "UnitPrice * 0.086",这个列的值就是名字为UnitPrice的列计算出来的,在创建表达式时,使用 ColumnName 属性来引用列。 2、第二个用途是创建聚合列 聚合列聚合通常沿着关系执行(有关关系的描述见下面DataRelation部分),如果order表有名为 detail 的子表,两个表之间通过order.orderid和detail.orderid两个列建立一个关系 DataRelation 对象名为“order2detail”,在主表order中就可以建立一个聚合列,将计算每个order在detail表中含有的所有item的价格的和:DataColumn.Expression = “sum(child(order2detail).price)",child(order2detail)表示通过关系order2detail联系到的子表,child(order2detail).price就表示子表的price列。 ◆ DataRow DataRow 对象没有直接在代码中使用的构造函数,一般是从具有一定结构的DataTable用NewRow()方法来新建一个DataRow对象。一个 DataRow根据其是独立的,还是属于某个DataTable,是否修改过,是否被DataTable删除等等不同的情况有不同的状态,由 DataRow.RowState属性公开,如下表: 成员名称 说明 Added 该行已添加到 DataRowCollection 中,AcceptChanges 尚未调用。Deleted 该行已通过 DataRow 的 Delete 方法被删除。 Deleted 该行已通过 DataRow 的 Delete 方法被删除。 Detached 该行已被创建,但不属于任何 DataRowCollection。DataRow 在以下情况下立即处于此状态:创建之后添加到集合中之前;或从集合中移除之后。 Modified 该行已被修改,AcceptChanges 尚未调用。 Unchanged 该行自上次调用 AcceptChanges 以来尚未更改。 一个DataRow对象刚被创建之后其状态是Detached,是孤立的一个存在,所以建立了DataRow之后在DataRow中的单元填充了数据后还要通过DataTable.Rows.Add(DataRow)方法将此DataRow添加到DataTable,DataRow添加到 DataTable后, 这个DataRow的状态就转变为Added。当修改了这个DataRow后,这个DataRow状态转为Modified,当用 DataRow.Delete()方法删除DataRow后,DataRow状态将转为Deleted,不过此行还存在在DataTable中的,只是状态改变了,这时用DataTable.Rows.Count查看行数,跟删除前是一样的。只有在调用了DataTable.Remove (DataRow)方法后,此DataRow才被从DataTable移除,状态也回复到Detached孤立状态。 一旦调用了DataTable.AcceptChanges()方法后,所有的行将根据不同的状态做不同的处理,Added、Modified、 Unchanged将保留当前值,Deleted的行将从DataTable中移除,最后所有的行的状态都置为Unchanged。当DataTable 是从DataAdapter.Fill(DataSet,DataTable)方法填充而形成的,Fill()方法将自动调用AcceptChanges ()方法,将DataTable的行状态都置为Unchanged。并且,如果Fill方法中指定的那个DataTable在要填充的那个DataSet 不存在时,会生成一个跟数据源表同样的结构的DataTable并填充数据。 ◆ DataRelation 表示两个 DataTable 对象之间的父/子关系。可以类比于数据库中的表之间的关系,父表相当于关系列为主键的表,子表相当于关系列为外键的表。DataRelation 构造函数一般为:DataRelation(String, DataColumn, DataColumn) ,string为关系名,第一个DataColumn为建立关系的父表列,第二个DataColumn为建立关系的子表列,建立关系的两个列的 DataType 值必须相同。 建立好了关系,必须把这个关系加入到DataTable的ParentRelations 属性或ChildRelations 属性,这两个属性包含这个表的所有的跟父表的关系和跟子表的关系。若关系中此表是父表则将此关系加入到ChildRelations集合中,否则加入到 ParentRelations集合中。 二、DataView DataView 表示用于排序、筛选、搜索、编辑和导航的 DataTable 的可绑定数据的自定义视图。可以将DataView同数据库的视图类比,不过有点不同,数据库的视图可以跨表建立视图,DataView则只能对某一个 DataTable建立视图。DataView一般通过DataTable.DefaultView 属性来建立,再通过通过RowFilter 属性和RowStateFilter 属性建立这个DataTable的一个子集。 RowFilter属性用来筛选要查看DataTable中哪些行的表达式,这个表达式同上面所说的建立计算列的表达式相同。例如:"LastName = Smith ",这就是只查看列LastName的值为 Smith 的那些数据行。 RowStateFilter 属性用来设置 DataView 中的行状态筛选器,上面介绍DataRow时介绍了DataRow的状态,一个DataRow可能有五种状态,RowStateFilter就是可以通过这些状态来筛选要查看的行集。其实DataRow不仅有五种状态,DataRow还有版本的问题,比如当DataRow的状态为Modified,即这行已经被修改了,这时这个DataRow就会有两个版本,Current版本和Original版本(修改前的)。实际上RowStateFilter属性是综合了DataRow的状态和版本来筛选的(RowStateFilter确省值是CurrentRows)见下表: 成员名称 说明 Added 一个新行。 CurrentRows 包括未更改行、新行和已修改行的当前行。 Deleted 已删除的行。 ModifiedCurrent 当前版本,原始数据(请参阅 ModifiedOriginal)的修改版本。 ModifiedOriginal 原始版本(尽管它后来已被修改并以 ModifiedCurrent 形式存在)。 None 无。 OriginalRows 包括未更改行和已删除行的原始行。 Unchanged 未更改的行。 DataView.Count属性得到的计数是在应用了 RowFilter 和 RowStateFilter 之后,获取 DataView 中记录的数量。 DataView 是建立在DataTable基础上的,DataView.Table 属性可以得到此DataView对应的那个DataTable。DataView的行叫DataRowView,可以从DataRowView直接通过 DataRowView.Row 属性得到此DataRowView对应的DataRow。 三、DataGrid 这里说的DataGrid是winform中的DataGrid,一般都是跟DataView绑定来显示DataTable中的数据,和修改DataTable中的数据。 DotNet的DataGrid的功能强大,可是在使用上与以前的习惯不太一样,有时还比较麻烦,所以很多人都对这个DataGrid感到有些摸不着头脑,有一种无从下手的感觉,其实把一些概念搞清楚了许多问题就会迎刃而解了。 DataGrid 通过DataSource 和 DataMember 属性来绑定其要显示的数据源。数据源一般是DataTable、DataView、DataSet等,不过将这些数据源绑定到DataGrid时实际上是绑定的DataView。若数据源是DataTable时,实际上是绑定了此DataTable的DefaultView,若数据源是DataSet时,则可以向 DataMember 属性设置一个字符串,该字符串指定要绑定到的表,然后再将DataMember指定的那个DataTable的DefaultView绑定到 DataGrid。 所以DataGrid实际显示的是DataTable经过筛选的DataView。 Virus&Firewall
PHP正则表达式 开篇,还是得说说 ^ 和 $ 他们是分别用来匹配字符串的开始和结束,以下分别举例说明 |