学XML最好的素材就是Open XML(原OOXML),很全面,也很强大,更有实用价值。

posted @ 2008-07-20 10:16 王弈博 阅读(208) | 评论 (1)编辑
    无意中网上看到介绍未来C#的文章:http://blogs.msdn.com/charlie/archive/2008/01/25/future-focus.aspx


    文章的大体意思就是,C#未来的发展方向肯定是面向对动态语言的支持这个方向了,也可以肯定的是C#将加入更多的动态语言的特性,这一点还是很值得期待的,文章中指出未来的C#将支持“dynamic lookup“的动态特性。

    目前透露的语法形式是这样:

    static void Main(string[] args)
    {
        dynamic
        {
            object myDynamicObject = GetDynamicObject();
            myDynamicObject.SomeMethod();         // call a method
            myDynamicObject.someString = "value"; // Set a field
            myDynamicObject[0] = 25;              // Access an indexer
        }
    }

    使用关键词“dynamic”,将想使用“dynamic lookup“动态特性的区域告知编译器,编译器将不在编译的时候检查“myDynamicObject”是否有下面的域或者方法,而是在运行时由DLR尝试强行调用这些东西,出错了再抛出异常。个人的理解就是,虽然支持所谓的“dynamic lookup”,但本质上还是需要全部编译为IL代码再运行的,本质上还是静态的,使用关键词“dynamic”的目的就是告诉编译器这里面不要做编译检查,让它通过,然后通过调用DLR部分功能,实现这种“dynamic lookup”的特性。

    文章还列举了采用“dynamic lookup“动态特性好处的三种场景:一个就是与COM组件的互操作上(这点我没大看懂,达人解释一下),一个就是可以更方便地调用IronPython or IronRuby的类,最后就是能更方便地使用反射创建实例和调用方法。

posted @ 2008-07-08 17:07 王弈博 阅读(189) | 评论 (0)编辑
    http://www.cnblogs.com/allenlooplee/archive/2008/06/01/1211520.html


    感慨博主清晰的思维和良好的态度,在此向宁波俱乐部转载一下。
posted @ 2008-07-08 12:56 王弈博 阅读(22) | 评论 (0)编辑

    突然间发现博客园具备强大的发牢骚功能。那就发个牢骚。

    I know how it works because I know why it works,这是我对待新技术的态度。也希望所有喜欢追逐新技术的仔细体会这句话。

posted @ 2008-07-08 12:47 王弈博 阅读(14) | 评论 (0)编辑
讨论:

1. Silverlight就是利用B/S部署方式的C/S架构。
2. Silverlight就是强类型化的B/S方案。



思考:

    你认为Silverlight将给业界带来什么样的影响?你打算怎么做?你将采用什么样的架构体系去使用Silverlight?Silverlight是flash killer还是html killer?

   
posted @ 2008-07-08 12:25 王弈博 阅读(218) | 评论 (7)编辑

    昨天中午吃饭时和一位同学谈论了权限管理的问题,在他的一个ERP项目中,要涉及很精细的权限控制,而他要负责抽象出一套比较通用的权限框架,用户权限一直是ERP开发中比较头痛的问题,而恰恰他的这个项目的用户权限需求又非常精细。甚感为难。

    恩......问题在哪里?回来后我也仔细思考了,我们未来向ERP领域进军,势必也要面对这样的问题。找出一套解决方案是很必要的。

    我不是一个喜欢循规蹈矩的人,这既是优点也是缺点。

    从抽象层次来讲,软件是一个很典型的轮回模型,小到OO的模型,大到未来的SO模型,一直是在资源、处理机环境(人还是CPU(OO层次),人还是面向服务的系统(SO层次))和处理方法中轮回,在哲学意义上,正好体现的是空间和物质(资源),时间(处理机环境)和物质联系(方法)。

    所以,权限管理本质上属于物质联系,属于工作流的,我们在抽象时必须非常清楚这个本质问题。权限管理本质上是用户资源和表单资源之间的相互联系,我们在设计工作流的时候就要好好想想了,权限管理应该在工作流的外面还是里面?当然,权限管理是特殊的,特殊性的根本原因不是因为它是个不同于工作流的另类的东西,而是在于一个工作流基本上都是由用户来发起的,属于工作流最初的起点部分,这样的场景才是权限管理特殊性的本质所在。而我们在实际处理的时候往往将权限管理从工作流中剥离出来,以至于很多企业想做一个通用的权限管理框架,我觉得这会有很大的难度。因为你要涉及权限管理就要处理用户资源,不同的系统的用户资源的表示方式是不一样的,与表单资源之间的联系也是不一样的。

    所以,一套软件系统的权限管理是和用户实际体系运作强绑定的,强行剥离去耦势必会带来很大麻烦。我的处理建议是,既然理论上已经讲明白权限体系很难单独从实际工作流中剥离出来,不如顺其自然,老老实实将它包括在实际的工作流里,利用WF这样基础的工作流平台的快速便捷性,降低项目开发、管理、维护成本。

posted @ 2008-07-07 12:31 王弈博 阅读(2047) | 评论 (22)编辑
 

宁波.NET俱乐部WCF讲座

目标:

尽量以全面和容易理解的视角系统和初步地讲解WCF,使得不熟悉WCF系统的会员能对WCF分布式技术有一个感性和直观的认知,从而使社区成员开始关心这一项技术,形成一个学习、讨论和交流的良好环境。在这样的环境中不断提高大家的整体水平。

主讲:王弈博

 

Hello WCF

 

WCF是什么?

WCF是一种在面向服务的理念下催生的分布式通讯技术解决方案。

为什么要面向服务

随着时代的不断发展,人们对于信息的处理不可避免的要越来越依赖网络。对于我们程序员来讲,面向WEB开发产品已成为不可阻挡的趋势。

但传统的网络体系是存在弊端的,弊端在于信息的提供者之间很难做有效的交流。我们将我们所拥有的信息以html的格式发送到客户的浏览器中,甚至使用更加封闭的原始C/S技术,对于最终用户来讲,他很容易去解读、获取其中的信息,但如果有另外的公司或个人想使用我们的信息和其它地方的信息去做整合分析或者应用,那将是很困难的事情。如图所示:



    所以,问题就在于,我们缺乏一个统一的全球性的数据信息表达方式,这导致虽然我们面向了WEB,但信息提供者之间仍然是相对独立和自治的,我们拥有上千亿的WEB资源,但我们却很难对这些资源作有效的整合和分析,以提供更为先进和强大的应用。

我们将场景的范围适当缩小,举一个实际一点的例子。

对于一个稍大一点的公司,各个部门分别同时使用很多不同的系统是很正常的事情,但传统的开发理念导致这些系统仍然是相对自治的,部门之间很难做有效的资源整合和复用,很多企业不得不面对重新部署新系统或者添加大量转换接口的痛苦选择,信息化不仅没有给企业带来更多的好处,反而造成了严重的负担。

同样在政府所提倡的政务信息化的今天,我们又何尝不为部门间无法有效地共享信息而烦恼?为什么我们至今无法建立个人诚信系统档案?

后来便有了面向服务体系的观点,数据提供者在WBE上发布获取数据的方法,从而让合法的数据使用者使用这些数据,而WEB服务使用者可以整合从多个WEB服务提供商那里得到的数据,为最终用户提供更有价值和更人性化的服务。

这样的WEB模式不仅实实在在地解决了传统方案的问题,也给用户带来了前所未有的便利,极大地扩展了软件公司的生存空间。

未来的WEB开发模式

下面的图可以很好地诠释未来的WEB环境:




不仅原来分治的系统被有效地整合复用,各种语言、操作系统、客户端表现技术都被有机地整合了起来,WEB应用将再一次获得极大丰富。当然这其中会涉及很多问题,比如版本控制,但这种面向服务体系的趋势已不可避免。

(其实我们将各个系统看成类,将WEB服务看成类所提供的方法,呵呵,又一个软件轮回。)

回到WCF

现在泛泛而谈就很容易理解了,WCF就是一种非常非常优秀的面向Web服务的技术解决方案之一,它是微软自家各种分布式技术的集大者,是积累在自家产品的丰富经验的基础上开发出来的,是.NET 3.0中最为重量级的技术,是一颗即将被广泛应用的新星。

所有分布式解决方案都遵循一个统一的传输协议:SOAP,并且要尽最大可能遵循WS-*的所有功能性规范,在这样的前提下,面向服务的体系才能真正有效地被建立。

在目前的所有分布式框架解决方案中,WCF最为完全和精准地实现了WS-*的一系列标准,在WS-*体系的后续发展中,微软的努力极大地推广了WS-*标准的发展,WCF自然成为业界效仿的典范之作,掌握好WCF,并且逐步深入它,你会逐渐清楚地认知整个WS-*体系,东西是微软的,但知识却是相通的。精通WCF,你就一定能精通所有的其他分布式技术。

WCF step by step

我们接下来感性地认识一下WCF。使用vs 2008 IDE先建立一个叫做“EasyWcfLibrary”的项目(使用WCF Service Library模板),如图:



 

随后依次建立一个“WCFServiceHost”的控制台项目,用来Host我们的WCF Web服务。再建一个WinForm项目,叫Client1,一个WPF项目,叫Client2。建完后如图:



接下来我们打开“EasyWcfLibrary”项目的IService1.cs文件,我们发现,模板自动给我们生成了这样的一个接口:




    并且在Service.cs文件中实现了这个接口:



面向接口的概念我不想在这里涉及,简单的说,Service1这个类型就是我们简单的一个将要对外发布的服务,别人可以通过WEB调用我这里提供的两个方法,并且无论是JAVA调用,还是C++调用,我们的系统即能正确识别传递过来的参数,结果返回值也能被这些系统正确解析(全赖SOAP协议和WS-*规范)。

不用把事情想得太复杂,你完全可以认为这就是一个DLL,只不过普通的DLL不能垮WEB被使用,而这个DLL可以。

接下来做的就是要在一个合适的地方运行这个DLL,这个地方就叫WCF Service Hoster,刚才我们建立了一个控制台项目,我们先引入一个叫“System.ServiceModel”的DLL,再将刚才的EasyWcfLibrary项目导入:





然后将EasyWcfLibrary项目中的配置文件:“App.config”复制到这个项目中。

最后填充Main函数,以启动WCF Web服务:



运行这个控制台项目,如图:很简单,服务启动了:



    服务正常运行了,接下来的问题是客户端如何调用这个服务,我们还是先不要涉及太多的概念,化繁为简地说,我们打开刚才复制的配置文件“App.config”,这里定义了很多东西,它们都是用来描述我们刚才那个WCF服务的,我们找到这里:



    复制一下这个地址。我们在浏览器中打开:



    我们很高兴地看到WCF服务被开启了,而且里面还有个地址,这个地址便是客户端用来获取WCF服务器端方法和类型定义相关信息的,我们打开看一看:


    关掉这个浏览器,我们回到vs 2008 IDE,我们在WinForm客户端中引用这个WEB服务:





    将地址填入,点击“Go”:



将Namespace改一下,如上图。点击“OK”,这样vs 2008 IDE就帮我们自动生成了一个代理类。

   

然后我们简单的设计个界面,并且写一下调用代码:





    首先我们需要new一个刚才生成的代理类,然后简单地使用之前我们写的WCF服务。

写完运行:



可以看到,我们已经成功地使用了WCF服务。

同样的步骤,我们在WPF项目中建立客户端,填写代码,运行:



不仅仅是WinForm还是WPF还是ASP.NET,你都可以调用WEB服务。

微软的东西从来都是入门简单上手快,但隐藏在后面的细节总是庞大的,就像C#,入门相当容易,但隐藏在后面的庞大的细节和原理如果没有非常扎实的计算机基础是不可能做到全面贯通和理解的,WCF涉及到庞大的WS-*规范,这不是我们今天能涉及到的内容,但使用WCF基本的流程步骤就是:定义一个WEB服务接口,实现这个接口,利用一个宿主将这个服务host起来(这个宿主可以是控制台,可以是WinForm,可以是IIS等等),并在配置文件中写明白你这个WEB服务的地址在什么地方(Address),用哪种基本的通讯协议去访问(Http或者TCP/IP或者其他等等)(Binding),你这个WEB服务定义了什么操作方法,这些方法会传递哪些类型(Contract),是否加密传输、线程池最大数量、客户端无响应所允许的最大时间等等等等。改写完配置文件后,你的WCF服务就搞定了。细节的工作WCF全部遵循WS-*标准替你完成了。

而客户端可以通过获取服务器提供的描述:wsdl,由IDE替你生成一个代理类,然后你在本地使用这个代理就可以了。

希望此节课能帮助大家对WEB服务的必要性有所了解,对WCF有一个比较好的初步认识,网上有很多一步步学WCF的教程,我相信经过我的初步讲解,大家能有一个比较清楚的初步认识, SO和OO是两个层次上的概念,OO解决的是如何处理好系统内部的问题,解决的是系统内部代码复用的问题,SO解决的是各个独立系统之间交互的问题,解决的是系统之间的功能复用,和资源交互的问题,一定要认清面向WEB服务编程的重要性。

下面是集体讨论时间,希望大家踊跃发表自己的看法.

posted @ 2008-07-06 16:48 王弈博 阅读(136) | 评论 (0)编辑
    前段时间宁波社区讨论了类型转换是用as关键字好还是用()好的问题,当时我轻易地相信了一片转载的文章的观点(http://hi.baidu.com/salangane0512/blog/item/24a7448b49011d17c8fc7aa9.html),认为用as比用()好。今天偶尔试验了一下,其实事情不是那样的,我当时的不严谨导致犯了一个小小的经验主义错误。

    看下面的代码:
   
    
    
//类型定义
    public interface I
    {
        
string Name { getset; }
    }

    
public class A : I
    {
        
public string Name { getset; }
    }

    
public class B : A
    {
        
public int Key;


        
public static explicit operator string(B operand)
        {
            
return operand.Name;
        }
    }


    
    
//方法调用
     private void button1_Click(object sender, EventArgs e)
    {
        B b 
= new B();
        A a1, a2;

        a1 
= (A)b;
        a2 
= b as A;

        
string h = (string)b;
    }

    对应调用方法的IL代码:
.method private hidebysig instance void button1_Click(object sender, class [mscorlib]System.EventArgs e) cil managed
{
    .maxstack 
1
    .locals init (
        [
0class WindowsFormsApplication15.B b,
        [
1class WindowsFormsApplication15.A a1,
        [
2class WindowsFormsApplication15.A a2,
        [
3string h)
    L_0000: nop 
    L_0001: newobj instance 
void WindowsFormsApplication15.B::.ctor()
    L_0006: stloc.
0 
    L_0007: ldloc.
0 
    L_0008: stloc.
1 
    L_0009: ldloc.
0 
    L_000a: stloc.
2 
    L_000b: ldloc.
0 
    L_000c: call 
string WindowsFormsApplication15.B::op_Explicit(class WindowsFormsApplication15.B)
    L_0011: stloc.
3 
    L_0012: ret 
}


 

    这下很清楚了,()和as在做类型转换的时候都是一样处理的,根本不存在所谓那个性能好那个性能坏的问题,完全是受个人习惯影响的。

    使用as唯一的好处是可以分清你是在做基于基类和接口的类型转换还是使用操作符重载机制(CLR编译器层处理)的类型转换(后一种本质上就是调用一种方法!!)。比如例子中的: string h = (string) b; 。这是使用as替代()操作符的唯一好处,而不是那篇文章中长篇大论讲的那样。

    判断类型用is,转换的话最好用as,只是因为这样清楚一些。

    大家在工作交流中经常会犯一些不严谨的错误,我在此先作自我批评,希望大家平时多加注意和改正。
posted @ 2008-07-05 12:12 王弈博 阅读(178) | 评论 (4)编辑
    社区里经常有人问这样的问题:“什么时候用LINQ?”。

    什么时候用LINQ?为什么用LINQ?LINQ有什么好处?

    1. 首先,如果你们的项目组没有SQL很强的人,我还是很希望你用LINQ。

    2. 如果你是一个反对写存储过程,反对将业务逻辑带入数据库层,并且坚定地认为数据库只是发挥持久化数据作用的人,我觉得你也会很喜欢LINQ的便捷性。

    3. LINQ提供了一个统一的数据集访问方式,如果你的项目不仅仅涉及访问传统的数据库,而且还要涉及比较多内存数据集查询(比如操作Dictionary<,>),甚至XML型的数据库文件,那我强烈建议你使用LINQ,统一的数据集访问方式对项目管理还是很有好处的,不然这个人用这种方式取内存数据、那个人用那种方式取XML数据......你这项目要侵入多少额外的操作类?看着都愁就更不用说去好好的管理了。

    4. LINQ to sql的操作是缓存的,事务的,如果你不想花很大的精力去优化数据库访问,用LINQ是一步到位的,绝对节省项目精力,提高项目质量。而且LINQ to sql的速度优化还是很好的,更不用说以后的ADO.NET ENTITY了。

    5. 需求的变化经常导致需要在数据库中更改字段,这是头痛的,也是无可奈何的,目前也没什么太好的办法去解决。但是如果你的项目中用的是sql语句字符串操作数据库,那你就要更头痛了,一个个更改这些字符串,但项目大了总会有遗漏,运行时碰到了才会出错,有时候甚至时间长了你会忘记你曾经更改过数据库字段,那就更麻烦了。如果你用LINQ,虽然你还是要一个地方一个地方去改,但只要你更改过数据库,在VS 2008 IDE里更新过更改的表,等你再一编译就会把错误的地方全部找出来,这样问题就相对小了很多。

    6. sql注入式入侵大家再也熟悉不过了,我的查询是用LINQ to sql写的,你入侵看看,呵呵。no way!


    同志们,赶紧装上vs 2008用LINQ吧,vs 2008不仅运行速度比vs 2005好不少,而且绝对完完全全是兼容vs 2005的(绝对不同于vs 2003到vs 2005的升级),你不懂C# 3.0什么的都没任何关系,完全不影响使用,而且vs 2008非常完美地支持JavaScript和ASP.NETAJAX的智能感知和调试。现在还不用,实在太浪费啦。
posted @ 2008-07-02 11:47 王弈博 阅读(219) | 评论 (1)编辑
    图片验证最常用在防恶意注册的场景,但传统图片验证方法的缺点在于需在服务器端维护这些随机生成的验证码字符串,所以实质上只是将恶意注册的影响从数据库转移到了内存,维护这个内存资源仍然会带来一些麻烦,包括定期清理,且仍要在一定程度上考虑防恶意获取验证码。

    下面介绍一种无需在服务器端维护验证码字符串的方法。

    我们假设服务器数据库用户表中的用户名字段的值必须是唯一的(这很常见),我们借助一个加密或者哈希算法,这样每个用户名对应的加密字符串在统计上也可以认为是唯一的。当新用户申请注册的时候,先提交这个用户名给服务器作有效性检查,如果数据库中没有这个用户名,则可注册,这时再用这个加密或者哈希算法将这个可用的用户名加密,返回这个加密的值的图像数据给客户端。(因为客户端不知道加密密钥,又不好破解加密算法,所以只能老老实实按图像值输入)

    随后客户端进入正式注册阶段,客户端将这个图像的对应字符串和刚才验证通过的用户名再次递交给服务器,服务器再次用同样的算法加密这个用户名,并将加密出的值和客户端传来的字符串相比较,如果相同,则向数据库提交注册。客户端也无法使用以前的验证数据来欺骗服务器,因为验证数据必须包含用户名,验证数据若有效则用户名必定已存在于数据库中,这样是不可能插入成功的。

    其实这个算法巧妙地借助了数据库某个字段值唯一性的特点,巧妙地复用了数据库的功能。

    优点:无需维护Session,对于服务器系统,越少维护这样的“全局变量”越利于减少出错几率。

    缺点:(可能,没测过,很有可能不是缺点)加密算法消耗的CPU时间要高于字典、hash算法(Session是需要通过字典或者hash算法获取数据的)

    只讲原理
posted @ 2008-07-01 00:06 王弈博 阅读(153) | 评论 (3)编辑