最近看黄忠成的书<深入剖析ASP.NET组件设计>
这本书的第二章和第三章对于从未编写过ASP.NET组件的开发人员来说,不是很容易看懂
为什么呢,不是黄先生讲的不好,而是因为.NET的类库太庞大,而ASP.NET的POSTBACK机制太诡异了
就像当初学VISUAL C++的时候,被MFC累死一样,很多人可能一看第二章,又是attributes,又是REFLECTION,又是CODEDOM,又是COLLECTION类,不下十几个类,很快就会让你觉得乱七八糟
而第三章更不得了,可以说真的是把ASP.NET剖肠破肚了,特别是讲由IIS到PAGE对象这一节,非常精彩,不过,却不是那么容易领悟
我在看这本书的时候,第二章第三章基本上是看了三遍
第一遍仅仅看懂了第二章的CODEDOM,第二遍搞懂了ATTRIBUTE和COLLECTION,第三遍看懂了第三章
为什么呢,因为我是从ASP.NET开发人员朝组件人员过渡,ASP.NET开发人员关心的不是COLLECTION或者ATTRIBUTE的实现原理,而是如何用,可是,作为一个组件编写人员,需要明白的是其如何实现和内部机理,因此,转变不可谓不大
其中ATTRIBUTE部分,我觉得这本书讲得过于高深了,其实ATTRIBUTE就是属性嘛,要实现一个属性的过程是,编写一个继承自ATTRIBUTE的类,然后接着把这个属性贴在某个类或者类的方法或成员上,贴上去了以后,有什么用呢?这就是大多数ASP.NET开发人员比较迷惑的地方,其实当一个类或者类的方法拥有某个属性时,接下来,在此类的实例中,你就可以用REFLECTION的方式反过来存取此属性,属性在整个过程中的作用跟生活中贴在某个物体上的标签是非常相似的,作用就是让使用的人(类实例)明白,噢,这是一个XX物体,属性携带了对象的附加信息,这就是谜底了
可是,ATTRIBUTE在语言中的实现,是比较新的事物,所以,不容易理解,可是在,生活中,这样的例子已经很多了,另外,我发现,计算正沿着生活中的一些规律来发展,或者说,它沿着我们人类的思想在发展,再说明白点,现在人们越来越善于把人类世界的一些哲学和方法在计算机上实现了,比如组件,接口,属性,组件就像生活中的车胎,接口好比水管上的三通
这本书的第二章和第三章对于从未编写过ASP.NET组件的开发人员来说,不是很容易看懂
为什么呢,不是黄先生讲的不好,而是因为.NET的类库太庞大,而ASP.NET的POSTBACK机制太诡异了
就像当初学VISUAL C++的时候,被MFC累死一样,很多人可能一看第二章,又是attributes,又是REFLECTION,又是CODEDOM,又是COLLECTION类,不下十几个类,很快就会让你觉得乱七八糟
而第三章更不得了,可以说真的是把ASP.NET剖肠破肚了,特别是讲由IIS到PAGE对象这一节,非常精彩,不过,却不是那么容易领悟
我在看这本书的时候,第二章第三章基本上是看了三遍
第一遍仅仅看懂了第二章的CODEDOM,第二遍搞懂了ATTRIBUTE和COLLECTION,第三遍看懂了第三章
为什么呢,因为我是从ASP.NET开发人员朝组件人员过渡,ASP.NET开发人员关心的不是COLLECTION或者ATTRIBUTE的实现原理,而是如何用,可是,作为一个组件编写人员,需要明白的是其如何实现和内部机理,因此,转变不可谓不大
其中ATTRIBUTE部分,我觉得这本书讲得过于高深了,其实ATTRIBUTE就是属性嘛,要实现一个属性的过程是,编写一个继承自ATTRIBUTE的类,然后接着把这个属性贴在某个类或者类的方法或成员上,贴上去了以后,有什么用呢?这就是大多数ASP.NET开发人员比较迷惑的地方,其实当一个类或者类的方法拥有某个属性时,接下来,在此类的实例中,你就可以用REFLECTION的方式反过来存取此属性,属性在整个过程中的作用跟生活中贴在某个物体上的标签是非常相似的,作用就是让使用的人(类实例)明白,噢,这是一个XX物体,属性携带了对象的附加信息,这就是谜底了
可是,ATTRIBUTE在语言中的实现,是比较新的事物,所以,不容易理解,可是在,生活中,这样的例子已经很多了,另外,我发现,计算正沿着生活中的一些规律来发展,或者说,它沿着我们人类的思想在发展,再说明白点,现在人们越来越善于把人类世界的一些哲学和方法在计算机上实现了,比如组件,接口,属性,组件就像生活中的车胎,接口好比水管上的三通