组件技术

何谓组件技术？组件技术有什么作用？为什么要应用组件技术？如何应用组件技术？我们现在都知道什么？我们现在应该做什么？又能做什么？当这些问题缠绕在心头时，也许您自己也承认，不得不学一学组件技术了，其码要了解组件技术(组件技术本文以后将以组件代替)。那么现在问一问自己，你是如何看待组件的？你心目中的组件是一个什么样子呢？感觉很好说，也许每个编程的人员对组件都有一个轮廓的概念，是的，Windows平台已经用了快十多年了，怎么能没有听过组件？从大的方面而言，当MS应用了OLE的时候，组件已经在慢慢的发展着，从最初的OLE 到COM 到CMO+甚至到了现在的.Net，无处不见组件的存在，然而这仅仅是一个轮廓的影响，我想，在学习组件的时候，首先应该明白一些基本的概念。而写这篇文章的最终目的就是要回答开篇是提出的几个问题以及教您如何写组件(本文将以编写一个ocx组件、应用MTS组件、COM+组件结束，而对于COM+ 就是MTS的更新版本所存在的某些歧义也将给于解释)。


何谓组件技术？具体死板的概念在各种书籍上有很多的定义，组件技术就是利用某种编程手段，将一些人们所关心的，但又不便于让最终用户去直接操作的细节进行了封装,同时对各种业务逻辑规则进行了实现，用于处理用户的内部操作细节,甚至于将安全机制和事物机制体现的淋漓尽止。而这个封装体就常常的被我们称作组件。或许这个定义有些勉强，但这样的解释对现在的你是有帮助的，而这个封装的过程中，编程工具仅仅是充当了一个单纯的工具罢了，没有什么实际的意义，也就是说为了完成某一规则的封装，可以用任何支持组件编写的工具来完成，而最终完成的组件是与语言本身已经没有了任何的关系,甚至可以实现跨平台。对我们而言，它就是实现了某些功能的、有输入输出接口的黑匣子罢了。


组件有什么作用？这个问题似乎有些笼统，试着想一想windwos何以实现如此强大的生产力？而在它的背后到底有什么在服务着？一句话：组件就是windows的灵魂，脱离了组件，windows系统将不再如今天一样如日冲天，windows如此，Unix也同样是如此，作为一个操作系统，它所完成的功能无不提体着组件的服务，一个很轻松的Copy – Paster都要靠DDE来支持，而DDE就是一种组件服务对象，而具体到某一个细节，如今的大型ERP靠的是什么？多层系统又靠的是什么？组件！组件封装了系统运行的各种规则甚至运行环境，而组件又何以完成如此多的服务？这儿就不得不提起组件对象，所谓的组件对象是组件的一个集合，而这个集合又并非是随意性的组合，必须要考虑到组件对象中的各个组件的协调功能，虽然，在理论上讲，一个组件对象里的各个组件应该是互不干涉、互不影响的，但是这并不意味着组件对象就是一个无协调的组件的集合，我们必须理解，通过访问一个组件对象中的某个组件，就有可能访问此组件对象中的另外的组件以此循环下去.而这些都由谁来管理？肯定是组件对象，可以这样理解：组件有其自身的规则实现，而规则的实现又提体到了接口的实现，但是组件对象本身也是一个组件，它也有业务逻辑规则需要处理，它也要起到所集合的组件的协调。如此一来，可以能过某一个组件对象来协调的实现一些、一部分的业务逻辑规则！而对于应用者来说，这一切完全没有必要去得知，甚至是没有意义的。


为什么要应用组件技术？或许你会说，我们通过编程的手段同样可以处理一些简单的或稍微复杂的业务规则，的确，不否认，通过编程的手段我们可以实现如组件对象一般实现的规则处理。然而如果仅仅是因为此我们就说组件对象或组件和我们平时的编码是一致的，那么现在可以明确的告诉你，这是一个很糟糕的想法。使用组件技术的的目的是实现各种规则{你想要实现的规则}的实现，而且组件对象还将从更广阔的方面来考虑，它能将一个大型的分布式系统进行统一的规划、合理的处理冗余、安全、平衡负载……等单纯的编程手段不能实现的功能，这就是我们要应用组件的一个很重要的原因。再者，组件对象不是普通的可执行文件，更不是将各种规则定死在其内部，它可以很平滑的实现自身的升级、扩展(前提:不大量的更动接口)，举一个很简单的例子，当我们发现某项业务逻辑规则已经很陈旧的时候，我们不得不用新的业务逻辑规则去替换它，而这个替换过程将会提现出组件对于普通的.Dll文件或是.Exe可执行文件的具大差别。当我们需要进行更新的时候，对于组件对象而言，在最理想的情况下用户可以一边进行组件对象的应用，一边无知觉的接受新的组件技术，而试问一个Dll文件或是某一个可执行文件可以达到这样的效果吗？答案是否定的。如果你说这些理由还不够的话，我可以举出很多的应用来说明组件应用的必要性，然而，理由实在太多，也没有必要一一列举，你可以参考其它的技术资料或是在平时的操作中去发现。


如何应用组件？在这点上或许我们更关心的是我们如何通过编程的手段来实现组件，在开篇的时候已经提起过，组件就是利用某种编程的手段来封装业务规则，而且也强调了语言在此处仅仅是一个工具罢了。但你可以完整的写出一个组件的时候，那么对于其应用就会更明确，对其给工作带来的效率而惊叹不已。那么到底如何应用组件技术？组件技术属于高组的应用部分，它可以从系统的底层作起，一直到我们可以感觉的明显出来的功能的封装。而在此过程中，我们就是要通过自己熟悉的工具来写一个好的组件对象或是组件。


我们现在都知道什么？虽然组件技术属于高级编程范畴，但是只要它是可以编程实现{又有那一种技术不可以实现呢？}的，我们就可以去实现一个组件。并且我们已经知道了组件的应用、作用，那们我们现在所应该做的就是熟悉一门开发工具，所谓的工欲善其事，必先利其器就是说我们只要很好的掌握了一个工具才有可能跨进组件技术这个大门(请不要在组件技术是语言无关性上和此处的表达方式进行纠缠，再如何的语言无庆性也必须要靠工具去实现，不是吗？)，否则就算对组件技术理解的再透彻也只能站在门外徘徊。所以我们现在知道的无非就两点：组件和我们所掌握的工具。


我们现在应用做什么？又能做什么？没有基石的大厦必将会倒塌，我们没有坚实的基础做后盾，那么我们所写出来的组件必将也是一些垃圾！或是不成形的玩具罢了。或许你对组件很了解，而且也很明白FrameWork的设计，但是这一切都是建立在对其内核不理解的基础这上，只能说这是一种空白的设计，因为你将无法的切身体会的那种设计模设将会给你的组件带来质的飞跃，组件如此，其它也如此，就如一个好的项目经理需要有灵敏的思维和高超或是相当不错的技艺一样，否则，别人只会认为他在空谈自己的构想。所以我们现在应该做的就是充分的理解组件的应用之处、组件自身的规则以及我们的开发利器。这就是我们应该做的而且也是我们目前唯一可以做的。


当我们对组件有了一个基本的轮廓或是比较清楚的影响时，下一步就是来将我们的工具与组件结合起来。每一个开发工具都有其自身的特点，不同的语言虽然可以实现某些相同的功能，甚至被人们所说使用何种开发工具都一样的言辞所一概而论，此时我们就应该意识到这点是错误的，因为开发工具都有其利有其弊，应用其利是我们应该做的(并非是要大家对弊端弃之)，此为其一，另外我们也必须要知道用什么样的技术所实现的更能给我们的组件带来效益上的飞跃、冗余上的放心、负载平衡上的可靠等。到现今为止，我们在熟悉我们的开发工具的同时还需要将面向对象编程的思想深深的渗透。为什么要这样说呢？.Net的Framework的设计模式给了我们很大的忠告，一个组件其实就是一个工程，一个项目，而实现工程、项目的最好方法就是充分的利用OOP思想，当然，如果你要是能确定你此处的版本是最终版本的话，倒也无妨，无非就是在此版本中的编码系统上复杂一些罢了。