自言自语

I'm Wang Xianyuan, writing for myself, more studying, more experience…

在C#程序中实现插件架构

By

在.NET框架下的C#语言,和其他.NET语言一样提供了很多强大的特性和机制.其中一些是全新的,而有些则是从以前的语言和平台上照搬过来的。然而,这种巧妙的结合产生了一些有趣的方法可以用来解决我们的问题。这篇文章将讲述如何利用这些奇妙的特性,用插件(plug-ins)机制建立可扩展的解决方案。后面也将提供一个简要的例子,你甚至可以用这个东西来替换那些已经在很多系统中广泛使用的独立的程序。在一个系统中,可能有很多程序经常需要进行数据处理。可能其中有一个程序用于处理雇员的信息,而另一个用来管理客户关系。在大多数情况下,系统总是被设计为很多个独立的程序,他们之间很少有交互,经常使用复制代码的办法来共享.而实际上这样的情况可以把那些程序设计为插件,再用一个单一的程序来管理这些插件。这种设计可以让我们更好的在不同的解决方案中共享公用的方法,提供统一的感观。
  
  图片一是一个例子程序的截图.用户界面和其他常见的程序没有什么不同.整个窗体被垂直的分割为两块.左边的窗格是个树形菜单,用于显示插件列表,在每个插件的分支下面,列出了这个插件所管理的数据.而右边的窗格则用于编辑左边被选中的插件的数据.各个插件提供各自的编辑数据的界面.图片一展示了一个精巧的工作区. 
  
  开始
  
  那么,主程序必须能够加载插件,然后和这些插件进行通信,这样才能实现我们的设计.所有这些的实现可以有很多不同的方法,仅取决于开发者选择的语言和平台.如果选择的是C#和.NET,那么反射(reflection)机制可以用来加载插件,并且其接口和抽象类可以用于和插件通信.
  
  为了更好的理解主程序和插件之间的通信,可以先了解一下设计模式.设计模式最早由Erich Gamma提出,它利用架构和对象思想来实现通用的通信模型.不管组件是否具有不同的输入和输出,只要他们有相似的结构.设计模式可以帮助开发者利用广受证明的面向对象理论来解决问题.事实上它就是描述解决方案的语言,而不用管问题的具体细节或者编程语言的细节.设计模式策略的关键点在于如何把整个解决方案根据功能来分解,这种分解是通过把主程序的不同功能分开执行而完成的.这样主程序和子程序之间的通信可以通过设计良好的接口来完成.通过这种分解我们立即可以得到这两个好处:第一,软件项目被分成较小的不相干的单位,工作流程的设计可以更容易,而较小的代码片断意味着代码更容易建立和维护.第二个好处在于改变程序行为的时候并不会关系到主程序的运行,主程序不用关心子程序如何,他们之间只要有通用的通讯机制就足够了. 
  
  建立接口
  
  在C#程序中,接口是用来定义一个类的功能的.接口定义了预期的方法,属性,事件信息.为了使用接口,每个具体的函数必须严格按照接口的定义完成所描述的功能.列表一展示了上面例子程序的接口:IPlug.这个接口定义了四个方法:GetData,GetEditControl,Save和Print.这四个定义并没有描述具体是怎么完成的,但是他们保证了这个类支持IPlug接口,也就是保证支持这些方法的调用.
  
  定制属性
  
  在查看代码之前,讨论总是先得转移到属性定制上面.属性定制是.NET提供的一个非常棒的新特性之一,属性对于所有的编程语言都是一种通用的结构.举个例子,一个函数用于标识可访问权限的public,private,或者protect标志就是这个函数的一个属性.属性定制之所以如此让人兴奋,那是因为编程人员将不再只能从语言本身提供的有限的属性集中选择.一个定制的属性其实也是一个类,它从System.Attribute继承,它的代码被允许是自我描述的.属性定制可以应用于绝大多数结构中,包括C#里面的类,方法,事件,域和属性等等.示例代码片断定义了两个定制的属性:PlugDisplayNameAttribute和PlugDescriptionAttribute,所有的插件内部的类必须支持这两个属性.列表二是用于定义PlugDisplayNameAttribute的类.这个属性用于显示插件节点的内容.在程序运行的时候,主程序将可以利用反射(reflection)来取得属性值. 
  
  插件(Plug-Ins)
  
  上面的示例程序包括了两个插件的执行.这些插件在EmployeePlug.cs和CustomerPlug.cs中定义.列表三展示了EmployeePlug类的部分定义.下面是一些关键点.
  
  1.这个类实现了IPlug接口.由于主程序根本不会知道插件内部的类是如何定义的,这非常重要,主程序需要使用IPlug接口和各个插件通信.这种设计利用了面向对象概念里面的多态性.多态性允许运行时,可以通过指向基类的引用,来调用实现派生类中的方法.
  
  2.这个类被两个属性标识,这样主程序可以判断这个插件是不是有效的.在C#中,要给一个类标识一个属性,你得在类的定义之前声明属性,内容附在括号内.
  
  3.简明起见,例子只是使用了直接写入代码的数据.而如果这个插件是个正式的产品,那么数据总是应该放在数据库中或者文件中,各自所有的数据都应该仅仅由插件本身来管理.EmployeePlug类的数据在这里用EmployeeData对象来存储,那也是一个类型并且实现了IPlugData接口.IPlugData接口在IPlugData.cs中定义,它提供了最基础的数据交换功能,用于主程序和插件之间的通讯.所有支持IPlugData接口的对象在下层数据变化的时候将提供一个通知.这个通知实际上就是DataChanged事件的发生. 
  
  4.当主程序需要显示某个插件所含数据列表的时候,它会调用GetData方法.这个方法返回IPlugData对象的一个数组.这样主程序就可以对数组中的每个对象使用ToString方法得到数据以建立树的各个节点.ToString方法是EmployeeData类的一个重载,用于显示雇员的名字.
  
  5.IPlug接口也定义了Save和Print方法.定义这两个方法的目的在于当有需要打印或者保存数据的时候,要通知一个插件.EmployeePlug类就是用于实现打印和保存数据的功能的.在使用Save方法的时候,需要保存数据的位置将会在方法调用的时候提供.这里假设主程序会向用户查询路径等信息.路径信息的查询是主程序提供给各个插件的服务.对于Print方法,主程序将把选项和内容传递到System.Drawing.Printing.PrintDocument类的实例.这两种情况下,和用户的交互操作都是一致的由主程序提供的.
  
  反射(Reflection)
  
  在一个插件定义好之后,下一步要做的就是查看主程序是怎么加载插件的.为了实现这个目标,主程序使用了反射机制.反射是.NET中用于运行时查看类型信息的.在反射机制的帮助下,类型信息将被加载和查看.这样就可以通过检查这个类型以判断插件是否有效.如果类型通过了检查,那么插件就可以被添加到主程序的界面中,就可以被用户操作. 
  
  示例程序使用了.NET框架的三个内置类来使用反射:System.Reflection.Assembly,System.Type,和System.Activator.
  
  System.Reflection.Assembly类描述了.NET的程序集.在.NET中,程序集是配置单元.对于一个典型的Windows程序,程序集被配置为单一的Win32可执行文件,并且带有特定的附加信息,使之适应.NET运行环境.程序集也可以配置为Win32的DLL(动态链接库),同样需要带有.NET需要的附加信息.System.Reflection.Assembly类可以在运行的时候取得程序集的信息.这些信息包括程序集包含的类型信息.
  
  System.Type类描述了类型定义.一个类型声明可以是一个类,接口,数组,结构体,或者枚举.在加载了一个类之后,System.Type类可以被用于枚举该类支持的方法,属性,事件和接口.
  
  System.Activator类用于创建一个类的实例.
  
  加载插件
  
  列表四展示了LoadPlugs方法.LoadPlugs方法在HostForm.cs中定义,是HostForm类的一个private的非静态方法.LoadPlugs方法使用.NET的反射机制来加载可用的插件文件,并且验证它们是否符合被主程序使用的要求,然后把它们添加到主程序的树形显示区中.这个方法包含了下面几个步骤:
  
  1.通过使用System.IO.Directory类,我们的代码可以用通配符来查找所有的以.plug为扩展名的文件.而Directory类的静态方法GetFiles能够返回一个System.String类型的数组,以得到每个符合要求的文件的物理路径. 网管联盟bitsCN_com 
  
  2.在得到路径字符串数组之后,就可以开始把文件加载到System.Reflection.Assembly实例中了.建立Asdsembly对象的代码使用了try/catch代码块,这样如果某个文件并不是一个有效地.NET程序集,就会抛出异常,程序此时将弹出一个MessageBox对话框,告诉用户无法加载该文件.循环一直进行直到所有文件都已遍历完成.
  
  3.在一个程序集加载之后,代码将遍历所有可访问到的类型信息,检查是否支持了HostCommon.IPlug接口.
  
  4.如果所有类型都支持HostCommon.IPlug接口,那么代码继续验证这些类型,检查是否支持那些已预先为插件定义好的属性.如果没有支持,那么一个HostCommon.PlugNotValidException类型的异常将会被抛出,同样,主程序将会弹出一个MessageBox,告诉用户出错的具体信息.循环一直进行直到所有文件都已遍历完成.
  
  5.最后,如果这些类型支持HostCommon.IPlug接口,也已定义了所有需要定义的属性,那么它将被包装为一个PlugTreeNode实例.这个实例就会被添加到主程序的树形显示区.
  
  实现
  
  主程序框架被设计为两个程序集.第一个程序集是Host.exe,它提供了主程序的Windows窗体界面.第二个程序集是HostCommon.dll,它提供了主程序和插件之间进行通信所需的所有类型定义.比如,IPlug接口就是在HostCommon.dll里面配置的,这样它可以被主程序和插件等价的访问.这两个程序集在一个文件夹内,同样的,附加的作为插件的程序集也需要被配置在一起.那些程序集被配置在plugs文件夹内(主程序目录的一个子文件夹).EmployeePlug类在Employee.plug程序集中定义,而CustomerPlug类在Customer.plug程序集中定义.这个例子指定插件文件以.plug为扩展名.事实上这些插件就是个普通的.NET类库文件,只是通常库文件使用.dll扩展名,这里用.plug罢了.特殊的扩展名对于程序运行是完全没有影响的,但是它可以让用户更明确的知道这是个插件文件. 中国网管联盟bitsCN.com 
  
  设计的比较
  
  并不是一定要像例子程序这样设计才算正确的.比如,在开发一个带有插件的C#程序时,并不一定需要使用属性.例子里使用了两个自定义的属性,其实也可以新定义两个IPlug接口的参数来实现.这里选择用属性,是因为插件的名字和它的描述在本质上确实就是一个事物的属性,符合规范.当然了,使用属性会造成主程序需要更多的关于反射的代码.对于不同的需求,设计者总是需要做出合理的决定.
  
  总结
  
  示例程序被设计为尽量的简单,以帮助理解主程序和插件之间的通信.在实际做产品的时候,可以做很多的改进以满足实用要求.比如:
  
  1.通过对IPlug接口增加更多的方法,属性,事件,可以增加主程序和插件之间的通信点.两者间的更多的交互操作使得插件可以做更多的事情.
  
  2.可以允许用户主动选择需要加载的插件.

转自:http://blog.csdn.net/cngkqy/archive/2008/01/16/2047230.aspx

用 AuthHeader 对 Web Services 进行身份验证

By

一 引言
 
随着Web Service的出现,其应用也是越来越广,同时也深受开发者的喜爱。下面我将引用一个实际应用例子说明本文的目的。
 
假设有一个网上购物系统LiveShopping。在LiveShopping上,当客户已经选好他自己想买的商品之后,接下来就该付帐了。LiveShopping可以直接用信用卡付帐。另外假设LiveShopping的电子付款是与VeriSign合作。也就是说LiveShopping是VeriSign的一个客户。假设VeriSign提供了一些Web Services供LiveShopping使用。假设这些方法是:
 
1.VerifyCC(string cc_no,string expire_date,float amt) 
2.ProcessCC(string transaction_type, string cc_no,string expire_date,float amt,CardHolder holder)
 
其中方法1验证信用卡是否有效,方法2是一个Transaction,将从信用卡上划出amt数额的交易款。
 
参数说明
cc_no 信用卡卡号码
expire-date 有效日期
amt金额
transaction_type 事务类型,比如说sale, force等等
holder 持卡人信息 
 
这里有个问题,如果VeriSign没有身份验证,那怎么知道客户是LiveShopping。换句话说,如果没有身份验证,每个人都可以使用这两个方法。所以身份验证必不可少。
 
二 实现身份验证
 
身份验证有很多方法,这里将介绍一种非常简单的方法,并且在.NET中实现。
 
可以应用WebService的Soap 头实现。也就是说可以利用Soap头传递验证的信息,比如用户名,密码等等。
 
首先从客户端看,可以对其应用有一个直观的了解。代码如下 
private void Button1_Click(object sender, System.EventArgs e)
{
    AuthHeader auth = new AuthHeader();
    WebServices webService = new WebServices();
    auth.UserName = this.txtName.Text.Trim();
    auth.Password = this.txtPwd.Text.Trim();
    webService.authHeader = auth;
    string rtStr = webService.GetPassword();
    this.txtReturn.Text = rtStr;
} 
解释一下,AuthHeader为前面提及的Soap头的实现,其定义如下:
public class AuthHeader : SoapHeader
{
    public string UserName;
    public string Password;
} 
继续看看WebServices是如何实现的,代码如下:
 
public class WebServices : System.Web.Services.WebService
{
    public AuthHeader authHeader;
    [SoapHeader("authHeader")]
    [WebMethod(Description = "This method will return the sensitive data")]
    public string GetPassword()
    {
        if (authHeader.UserName.Equals("user") && authHeader.Password.Equals("pwd"))
        {
            return "pwd";
        }
        return "Invalid Authentication ";
    }
} 
可以发现,加入了一个AuthHeader公共成员。这个可以供调用者传输验证信息。另外重要的一点是SoapHeader属性,它明确了Soap头。具体可以参见MSDN。
 
在GetPassword()中,可以加入你的代码。它第一步就是验证信息,如果验证成功,继续完成你的事情,如果不成功,则退出。
 
三 进一步
 
如果为了使应用更加安全,我们可以对数据进行加密,比如说我们可以对验证信息进行加密。可以在客户端进行加密,然后到了server端进行解密。加密和解密是另外一个话题,在这里不多假描述。
 
从性能方面来看,加密解密这个过程将会降低性能。所以一般可以折中考虑,只对于一些敏感的数据进行加密和解密,比如说密码等。除非是一些高安全性的应用,这时就另当别论了。

使用Forms实现WebService身份验证

By

在安全性要求不是很高的ASP.Net程序中,基于Forms的身份验证是经常使用的一种方式,而如果需要对WebService进行身份验证,最常用的可能是基于Soap 标头的自定义身份验证方式。如果对两者做一下比较的话,显然,基于Forms的验证方式更加方便易用,能否将Forms验证方式应用到WebService中去呢? 
 
从理论上讲,使用基于Forms的方式对WebService进行身份验证是可行的,但是使用过程中会存在以下两个问题:
1.基于Forms的验证方式同时也是基于Cookie的验证方式,在使用浏览器时,这个问题是不需要我们考虑的。但对于使用WebService的应用程序来说,默认是不能保存Cookie的,需要我们自己去做这个工作。
2.WebService既然是一个A2A(Application To Application)应用程序,使用Web表单进行身份验证显然不太合适,而且,这将不可避免的造成人机交互,使WebService的应用大打折扣。
 
接下来,我们就分步解决这两个问题:
1.Cookie的保存问题
WebService的客户端代理类有一个属性CookieContainer可用于设置或获取Cookie集合,保存Cookie的任务就交给他了:
 
System.Net.CookieContainer cookieContainer = new System.Net.CookieContainer();
MyService.WebService service = new App.MyService.WebService();
service.CookieContainer = cookieContainer;
 
2.我们不想使用Web表单进行身份验证,幸运的是,ASP.Net表单验证中的表单页(即Web.config文件中 forms 元素内的loginUrl)同样可以指定为WebService文件。
    我们创建一个专门用作身份验证的Web服务,暂且命名为Login.asmx,然后让 loginUrl 等于 “Login.asmx”,当然,还需要在Web.config文件中的 authorization 节中禁止匿名访问(否则我们可就白忙活了),完成配置后的Web.config文件如下:
 
<?xml version="1.0" encoding="utf-8"?>
<configuration>
  <system.web>
    <compilation debug="false"    />
    <authentication mode="Forms">
      <forms name="MyService" loginUrl="Login.asmx"></forms>
    </authentication>
    <authorization >
      <deny users="?"    />
    </authorization>
  </system.web>
</configuration>
 
其实我们并不想在未通过身份验证时让浏览器转向到Login.asmx,对于使用WebService的客户程序来说,真正的实惠在于:可以匿名访问Login.asmx中的方法(当然我们也可以把Login.asmx放在单独的目录中,然后允许对该目录的匿名访问来达个这个目的,但我觉得还是用loginUrl更优雅一些)。
接下来,我们为Login.asmx添加用于身份验证的WebMethod:
 
public bool Check(string userName, string password)
{
    if (userName == "aaaaaa" && password == "123456")//添加验证逻辑
    {
        System.Web.Security.FormsAuthentication.SetAuthCookie(userName, false);
        return true;
    }
    else
    {
        return false;
    }
}
 
最后一步工作就是:让客户程序中的WebService实例与Login实例共享CookieContainer。
 
class Sample
{
    System.Net.CookieContainer cookieContainer = new System.Net.CookieContainer();
    public void Login()
    {
        MyServiceLogin.Login login = new App.MyServiceLogin.Login();
        login.CookieContainer = cookieContainer;
        login.Check("aaaaaa", "123456");
    }
    public void ShowHelloWorld()
    {
        MyService.WebService service = new App.MyService.WebService();
        service.CookieContainer = cookieContainer;
        Console.WriteLine(service.HelloWorld());
    }
}
 
Login()以后再ShowHelloWorld(),你是否看到了我们熟悉的“Hello World”?Ok,就这么简单! 

近期准备打理论坛,以便更好地为博易用户服务

By

博易目前的 TroubleShooting 主要是通过用户交流群来做的。经过规划和考量,已打算把这部分工作转移到论坛上来。那么以后博易用户交流群仅用作用户之间的交流,而官方将把精力在论坛上去集中。这么做对博易的发展有一些好处。

A.内容归档,可追溯,减少重复的解答同样的问题。
B.内容共享范围扩大,原本仅在群内,而在论坛上的话可以扩大到所有Web浏览者。
C.交流可以异步。这么一来可以给双方都减轻工作负荷。
D.促使Web良性发展。论坛的帖子可以被搜索引擎收录,实现一个比较完备的Web的发展。
E.言论的所有权得以控制。

上面好处多多,是促使博易更好地发展的一个要素。不过也有不便之处,还请大家积极配合了。

区别不同浏览器,CSS hack写法

By

区别IE6与FF:
background:orange;*background:blue;

区别IE6与IE7:
background:green !important;background:blue;

区别IE7与FF:
background:orange; *background:green;

区别FF,IE7,IE6:
background:orange;*background:green !important;*background:blue;

修正 博易v1.7 二级分类链接的错误

By

群里面一位朋友提出了的,昨天测试了下,果然二级分类链接有问题。
回去之后修改好了,现在把改好的文件发出来给大家下载。
这个问题并不严重,如果你没有使用或者也不打算使用二级分类,可以不用下载。

这里是下载包,解压替换 App_CodeControls 下的相应文件即可。

CategoryList.zip (1.47 kb)