|
||
07 2008 档案
摘要：在前面的章节中，我们了解到Mussel是一个基于插件的应用框架。Mussel内核的本身不包含任何方面的功能，它只是负责对我们所编写的插件项目进行协调，维护起插件项目之间的依赖关起，并构建起插件项目之间的沟通渠道。通过编写各种不同的应用插件，我们可以无限的扩展Mussel的功能。同时，Mussel还可以按照用户指定的需求在进程中开辟不同的AppDomain，将不同职能的插件载入不同的AppDomain中，亦可以将相类似职能的不同插件加入到同一个AppDomain。在今天的讲述中，我们将看到如何利用Mussel默认提供的通信及Proxy生成器插件来开发一个简单的 C/S（客户端/服务器）应用
阅读全文
posted @ 2008-07-14 23:10
摘要：继续我们上一章的讲解。现在我们用一个具体的程序示例来演示我们插件的加载及卸载过程，我们先回顾一下上一章中我们总结出来的一些思路：
1. 建立一个新的AppDomain: AppDomain.CreateDomain()。
2. 利用的AppDomain的实例，采用 CreateInstanceFromAndUnwrap() 方法在新的AppDomain中构建一个指定的类型，并返回相应的Proxy。
3. 根据获取的Proxy就可调用插件了。
4. 卸载时，完成一些资源清理后可以直接对新建出的AppDomain进行UnLoad
阅读全文
posted @ 2008-07-12 10:21
摘要：在过去几年时间里，我一直都只是在看别人写的东西，属于那种典型的“看贴不回贴”的一类。自我感觉似乎这些编程语言社区与我没有太大的关系。总是在一些对问题摸不着头脑、急得只能干瞪眼时才想起来有这么一些积累了别人经验教训的地方，这个时候别人的博客文章，社区里面的一些技术文献便成了我救命的稻草。一直在社区中吸取营养，却未能给这片土地带来什么有价值的东西，呵呵，说起来真是惭愧！前段时间...
阅读全文
posted @ 2008-07-12 03:08
摘要：在软件开发的领域中，插件技术一直是一项非常实用的技术。许多优秀的软件产品都提供了通过加载插件来扩展、丰富产品本身功能的能力。而像Firefox、 Eclipse之类的软件，更是将插件的功能发挥到了极致。顺便做点广告的是，我们的Mussel框架便是一套基于插件扩充应用功能的框架：），在这里我们来分析一下.Net中常用的插件技术……
阅读全文
posted @ 2008-07-11 20:24
摘要：在前面的章节中，我们知道了如何利用DynamicProxy程序集从类及接口中进行方法拦截。现在我们可以做一个更有趣并且更实用的操作：我们利用前面章节所讲述的知识来完成一次调用指令的路由操作，借此让我们对Castle AOP的应用层面有一个更感性的认识，因为这一章节要讲述的内容稍微有些复杂，我会试图尽量的将这些内容讲解清楚，由于写文章的水平有限，如有讲解不周的地方也请大家谅解……
阅读全文
posted @ 2008-07-11 14:09
摘要：Castle中有一个扩展的DynamicProxy程序集(DynamicProxy2)，在这个程序集中，提供了对接口方法做动态拦截的能力。相比于对类方法的拦截，对接口方法的拦截为我们的架构设计方面提供了更大的自由度。在这里先罗列一些简单的代码，大家可以从这些代码中先思考一下接口方法的动态拦截可以应用于哪些方面，在以后的章节中，我们会深入的讨论具体的应用层面，其实这个在我们Mussel通信层的插件的实施中，于客户端产生服务端接口的 Proxy起到了决定性的作用……
阅读全文
posted @ 2008-07-10 11:59
摘要：熟悉Castle的朋友一定清楚：在Castle体系中，有一个叫Aspect#的子项目。Aspect#是一个AOP的框架，在这篇文章中，我并不打算直接开始讲Aspect#，因为Aspect#的封装过于完善，不太利于用来讲述AOP的具体实现细节。其实Aspect#的基础是 DynamicProxy，所以，我们先来讲讲DynamicProxy。
在很多朋友的眼中，AOP似乎是一个很神秘的东西，其实在我看来，AOP的本质就是对一切操作行为的拦截，在.Net中，AOP的本质更简单，纯粹是对方法的拦截。为什么这么说呢？因为在.Net中，一切的操作都是方法调用：事件的 “+=” 及 “-=”最终被转换为 Addxxxx(...)，Removexxxxx(...)类型的方法；属性的 get/set 过程也被转换为 getxxxxxx(...)，setxxxxxx(...)类型的方法；而方法的本身就更不用说了……
阅读全文
posted @ 2008-07-09 16:42
摘要：这是一个曾被热烈的讨论过的问题。之所以忽然谈起这个...
阅读全文
posted @ 2008-07-09 16:42
摘要：在上一篇文章中，我们讲过如何从外部调用插件项目，接下来我们来看看插件项目与插件项目之间的调用。
我们来看看现在的应用场景：同样是对两个数值进行运算，MathOne是基本并且稳定的运算服务，负责对这两个数据相加并返回值。但是由于新的用户的需求发生了改变，他们希望获得的值是MathOne结果的平方数，例如：
如果我们传入的值是 (2,3)，旧用户期望得到的值是 2+3 = 5 ，而新用户期望的值是 MathOne 运算结果的平方数，即是 5 2 = 25。
由于需要同时考虑新的需求并兼容旧的用户，所以我们需要加多一个插件项来为新用户响应需求。
为了让大家看起来不那么吃力，我们还是重述一下相关的接口及 MathOne 的实现
阅读全文
posted @ 2008-07-09 16:40
摘要：在之前的文章中，我们已经了解了Mussel插件项目树的结构及插件简单的制作方式，今天我们来看看如何对Mussel的插件项目进行调用。
我们想像一下有这样的一个应用场景：我们需要对两个数值运算并返回一个结果，这个运算交由一个独立的运算过程来进行，我们并不关心运算的具体细节，我们只需要运算过程返回一个结果，先来看看这个运算接口的定义
阅读全文
posted @ 2008-07-09 16:39
摘要：在之前的文章中我们提到了Mussel插件的层次结构：插件（Addin）包括了插件项目的装载节点(AddinNode)，装载节点又包括了插件项目(AddinItem)，而每个插件项目又可以包括无限下级的子项目：
Mussel的加载器在加载时，会尝试读取当前文件夹以下（包含子文件夹）的所有*.addin文件，每个addin文件被Mussel加载器识别、加载后，便会形成如上图所示的IAddin对象，如果每个插件都是独立的，这个过程就非常简单。但是插件之间必须然会有一些联系，例如，如果系统的工具栏是一个稳定的插件(addin)，如果金山词霸有一个扩展，能添加一个按钮到系统的工具栏中，我们先来看看摸拟的配置文件，为了方便说明，我们假定 ClassKey指示的类型都存在并忽略掉程序集引入的配置部分。
阅读全文
posted @ 2008-07-09 16:26
摘要：Mussel插件项目都从AddinItem继承，AddinItem类是所有插件项目的基类，附合IAddinItem接口规范，我们先来看看IAddinItem接口的构成类图：
上图是IAddinItem接口的全部方法与属性，从前三个属性中，我们不难看出Addin插件树的组成方式，可以想像的是AddinNode中自然还包插了IAddin的对像。
Properties属性是插件加载时，从Addin配置文件中读取的对应的AddinItem的配置信息。而通过this属性可以轻松的访问到当前插件项目的子插件项目……
阅读全文
posted @ 2008-07-09 16:11
摘要：在前面的文章中，我们说过，Mussel的内核是一个插件容器。Mussel本身不提供任何功能上的服务，所有的功能都由插件来提供。Mussel负责协调插件与插件、插件与容器以及容器与调用者之间的通信。
Mussel提供了一个装载器，这个在以后的文章中会讲到。装载器的Start方法调用时，装载器遍历Mussel程序集所在文件夹以及所有的子文件夹，搜寻 *.addin 的插件配置文件。在这里，我们先看一个addin文件的演示……
阅读全文
posted @ 2008-07-09 15:42
摘要：使用.Net开发已经有近三年的时间了，深刻感受到.Net给软件开发思想带来的巨大的变化。.Net一些独特的语法元素（如特性、委托等等）以及对线程、Domain等概念的完美的支持，无疑为软件架构师提供了巨大的设计优势。 从使用.Net的第一天起，我就一直期望能设计一个符合小组使用，通过简单配置即可协调好程序集之间相互作用的一套轻量级框架，在对Castle、PostSharp、NHibernate等...
阅读全文
posted @ 2008-07-09 15:32
|
||
浙公网安备 33010602011771号