• 2005-06-09

    Hello Hivemind

    Tag:向上走

    版权声明:转载时请以超链接形式标明文章原始出处和作者信息及本声明
    http://www.blogbus.com/dreamhead-logs/1257273.html

    Apache作为一个著名的开源组织,几乎涉足了Java企业级应用的方方面面,小到基本的类库,大到完整的应用。美妙的DI容器之争又怎么会少得了它呢!Hivemind便是Apache给我们的答案。


     

    从Hivemind的架构图中,我们可以看出,Hivemind原本是用来封装各种各样的服务,以提供给应用使用。从Hivemind文档中不断出现的“service”可以很好的印证这一点。不过,设计的结果让它成了一个DI的容器,它也由此迈上了一个更高的台阶。设计的结果让它成了一个DI的容器,由此迈上了一个更高的台阶。

    下面该问候Hivemind了。
    public interface Action {
        void execute();
    }

    public class HelloAction implements Action {
        private String name;   

        public void setName(String name) {
            this.name = name;
        }

        public void execute() {
            System.out.println("Hello, " + this.name + "!");
        }
    }

    public class Main {
        public static void main(String[] args) { 
            ClassResolver resolver = new DefaultClassResolver();
            Resource resource =
                new ClasspathResource(resolver, "config.xml");
            RegistryBuilder builder = new RegistryBuilder();
            builder.processModules(resolver);
            builder.processModule(resolver, resource);
            Registry registry =
                builder.constructRegistry(Locale.getDefault());
           Action action =
                (Action)registry.getService("hello.action", Action.class);
            action.execute();
        }
    }

    这里我们使用的是Setter Injection,对于DI容器来说,同时支持Setter Injection和Constructor Injection已经成为一种常态,只不过,有些容器对于某些注入方式有特别的偏好而已,于是,选择权转到了用户的手中。

    从这个例子我们不难看出,相对Spring的API而言,Hivemind的API使用起来有些复杂。下面两行代码就是一个让人困惑的地方:
        builder.processModules(resolver);
        builder.processModule(resolver, resource);
    如果说第二行代码是为了加载资源,那第一行就显得有些莫名其妙了。其实,它是用来加载Hivemind自带的一些服务。它之所以让人困惑,其主要原因就在于如果不加载这些服务,应用是无法运行的。对于老手,自然无甚所谓,而对于刚刚接触Hivemind的人而言,大家兴高采烈编写Hello的时候,哪里会知道有这些规矩的存在。通常,其结果就是给初学者以无情的打击。
    当然,照着Hivemind的Tutorial写代码可能不会遇到这种问题,因为它用了缺省的加载方式,这种方式需要把叫hivemodule.xml的配置文件放到META-INF目录下。而在实际的开发中,这种被限制的做法并不让人喜欢。

    在配置文件中,我们发现,服务的“接口”和“实现”是分离的。Java中关于分离接口和实现的种种好处大多适合在这里使用。当然,如果我们认为自己的服务不会发生改变,把接口与定义放在一处也并无不可。
    Hivemind为用户提供了一个工具,用来从配置文件中提取相关的内容生成一个便于阅读的文档,这便是Hivedoc。我们可以把它理解成JavaDoc,通过它,我们可以将文档从“源码”中分离出来。
    Hivemind允许在配置文件中对配置的格式进行自定义。这样,如果某个服务得以复用,那么就可以利用这个功能简化配置文件的编写。对Spring用户来说,这可是一个充满吸引力的功能。这一功能的实现借鉴了Commons Digester的表现形式,巧妙的将规则描述同对象生成融合在一起。

    与其它DI容器稍有不同的是,Hivemind在容器一级上就把AOP的概念加了进去,在配置文件中,我们可以通过配置Interceptor,拦截对某个service的调用。Hivemind可以在配置文件中很简单加入一个Aspect,而不像Spring那样,需要绕一个弯子。这种差异就像把一个功能以语言特征还是以库的形式提供一样,对比C++中同步的处理手法,想想Java中的synchronized就不难理解这一点。“语言设计就是库设计,库设计就是语言设计”,二者在开发者的层面是可以很容易相互转化。究竟如何选择,完全取决于开发者的态度。

    分享到:

    历史上的今天:

    欢迎回归 2010-06-09
    初始化游戏 2004-06-09
    引用地址:

    评论

  • 很是新鲜呀,不知和Spring比哪个更有前途呢,听你的介绍似乎是加了新的东西,有时间得看看啦
    回复tracy说:
    了解了Spring再来看Hivemind,只是形式上的不同而已。我是为了对比Spring才写了这篇的。
    2005-06-13 08:58:53