Yan Container beta 1 发布

好吧。我自己提一点。

在lifecycle的支持上，虽然我相当自信我的设计比pico的好，但是，我实现的功能和pico是不同的。

pico和spring似乎都只支持在singleton上的lifecycle。pico的start(), stop()也只对singleton才有意义。因为如果不是singleton，你stop()的根本就不是你start()的那个对象。这好像很怪。

但是，直接使用起来，pico的api似乎简单些。

pico.start()就同时既实例化组件也对这些组件调用start()。

而我的实现是不同的。我不区分是否是singleton，反正每构造一个实例我都记录在案。（暂时用的强引用，回头可以改成弱引用）

调用init(), start(), stop(), dispose()的时候我并不构造新的实例，而只是遍历已经构造出来的实例。

如果在一个实例都没有构造出来之前，先调用new DefaultLifecycle(yan).start()，象pico那样，是不起任何作用的。

和pico.start()等价的是：
yan.getInstances();
new DefaultLifecycle(yan).start();

麻烦些，用户接口也复杂些。

我现在怀疑的是，我这样做是否合适？你们平时用lifecycle都是怎么用的？

唉，牛皮别乱吹。

怎么处理组件之间依赖性的？比如A组件启动（或者init吧）倚赖B组件的启动（或者init吧），这种情况。

还有，怎么动态改变某个组件运行中的属性？

呵呵，刚刚看完JBOSS的JMX框架以及启动框架，拿你的跟jboss比了下。sorry哦。

I'm glad that finally someone stands out.



are you talking about lifecycle?

new DefaultLifecycle(yan);.init();

does it all.



do you mind elaborating a bit? don't think I understand the question.


good good. You are absolutely welcome.
If you could point out anything that Yan cannot do or does not do well, you are helping me.
Jboss is more than an IOC container, while Yan is strictly a light-weight IOC container.
If the problem you find is within the IOC container scope, you got me.

我英文很烂，不过基本上能看懂你写的东西 。谈谈我的一些想法。我以JBoss为例子。

你的yan container代码我没有细看，我只是从一个能称之为container的东西出发来说点东西，说的不好，请见谅 。一般来说，能叫container的东西都不简单，呵呵，能写container的人，我觉得也不简单。

first，container－容器，容器是用来干吗的？用来装东西的，在java里面，或者从基于组件开发角度来看，是用来装组件的，对吧，container管理着容器里面的各个组件，管理着组件的生存周期，从组件的init到destory。

各个组件之间肯定会有关系，比如说A组件的启动倚赖于B组件的启动，如果B组件没有启动，则A组件没有启动，看Jboss的配置文件：

   <mbean code="org.jboss.tm.TransactionManagerService"
      name="jboss:service=TransactionManager"
      xmbean-dd="resource:xmdesc/TransactionManagerService-xmbean.xml">
      <attribute name="TransactionTimeout">300</attribute>
      <depends optional-attribute-name="XidFactory">jboss:service=XidFactory</depends>
   </mbean>

jboss:service=XidFactory这个MBean定义：

   <mbean code="org.jboss.tm.XidFactory"
      name="jboss:service=XidFactory">
      <!--attribute name="Pad">true</attribute-->
   </mbean>

红线的配置就说明jboss:service=TransactionManager这个组件倚赖于jboss:service=XidFactory 这个组件。我以启动为例子，如果jboss:service=XidFactory 没有起来，则org.jboss.tm.TransactionManagerService就起不来。

Second，怎么动态改变一个component的运行中的属性。
这个问题是这样的：这些组件跑在你的container里面，我想在某个组件运行中，查看这个组件的某些属性，或者修改这个组件的某些属性。举个例子说，我自己写了个组件，这个组件开了个ServerSocket，接受来自远端的客户连接，我想在这个组件跑的时候，看到有多少个客户连接上来了，看到某个远端的客户发了多少消息之类的。

好像这个问题可以这样解决，定义这个组件能暴露给外面能够使用的一些方法，呵呵。但是JMX在这方面做的比较好，不知道yan container在这方面是怎么做的呢，相信应该做的比较好吧。

PS：我GF的名的拼音就是yan，所以我看到yan这几个字母特别亲切，不知道跟你有关系的人名是不是yan，呵呵。希望你能做的更好。

JBOSS里面的container是以jmx为基础的，jboss自己搞了一个XMBean的冬冬出来，继承model mbean这玩意，呵呵。

我的邮箱：cxj_2000@hotmail.com，欢迎一起交流技术问题。

Firstly, thank you for your time.

I might not completely understand your explanation.


Since I do not know Jboss, my answer might be completely pointless. My apology if that's the case.

What you just described, seems quite out of the scope of an IOC container. An IOC container is only responsible for assembling components (And optionally control the instance lifecycles)
These things should be transparent to the business object. i.e. when you design your business object, you should not be aware of the existence of an IOC container.

For the 1st issue in your description, Yan, Spring, Pico all offer a lifecycle support that's gonna traverse all the component instances in certain order.
For example, if XidService is a dependency of TransactionManager, you can choose to start XidService and then TransactionManager.

For the 2nd issue, it sounds more like a Service, something like JTS, JMS that your business object can call. I don't think an IOC container should cover that. It looks to me very orthogonal to what IOC is supposed to do.

继续，还好有金山词霸，呵呵。

也许是我理解IoC错误，但是我觉得如果一个可以称之为Container的东西就是用来组装一个个Component，功能是不是太简单了，也许是我孤陋寡闻。

或者说这个container的冬冬组装compoent之后，对这个compoent啥都不管了，有时候想想，还不如new来的快，起码那些初级java程序员看代码方便些，呵呵。

昨天晚上跟领导喝茶，也提及这个问题，你用什么AOP，IoC之类的，刚刚毕业，或者那些刚毕业一年的人根本难以理解这些东西，你说这项目几个人一起做，你说用AOP，IoC开发速度能快，重用性好，但是对那些刚刚上手的java程序员来说，无疑是场灾难，等他们熟悉AOP之后，项目已经过半了。

说了些题外话，不好意思。

cxj_2000:

IoC,AoP,JMX是不同的概念,应用于不同的领域，虽然它们都是基本组件的设计思想，所谓的IoC Container就是起一个装配器的功能．

你好象对这些新的概念有抵触情绪，实际上这些名词都是用在系统架构上的，目的也主要是提供最大的灵活性来组织代码，下面实现业务代码的程序员不需要很深入理解这些东西．



ajoo:

呵呵，你终于出手做了个这个东西，我可是从你一开始到处询问IoC的概念就开始注意你了．对于你的这个Container我提不出什么意见出来，毕竟你的强项在于库一级的系统设计．我现在最关心就是这个框架在实际应用中的效果了，我打算在我所在项目中的一个子模块里应用一下，看看实际性能如何以及同事们的接受程度．

另外，你想过没有对你的这个框架增加一些扩展，例如对AoP的支持．毕竟从实际使用上来说，在程序员一级来看，如果只是起一个装配器的功能而要学习一大堆概念，还要熟悉你这个产品，那还不如自己做一个工厂来的简单．

从系统构架一级来看，只是起一个IoC的作用功能未免太过单一了，我想大家在选择架构一类的产品时主要是看是不是能解决系统设计中的大部分问题，并提供最大的灵活性．如果能对目前市场上流行的一些产品提供具体支持最理想，这样推广你这个框架会更容易一些．不过似乎要走Spring的这种模式了，呵呵，一家之言.

我也是这样的意思，从系统架构一级来看，一个container就做assemble，功能太单一了，container应该是起管理作用的，而不是简单的装配就over了。

That is exactly what I was thinking when I first heard of "IOC Container". 

And that is why I always say "IOC container" should be simple, because its responsibility is a simple task!

I once asked the same question on Jdon

But I got no answer that made sense.


And even today, I'd still say this view is reasonable.

Many people use IOC container as a super factory. That's why they need to know the container API. But that's an anti-pattern. Don't do that!


A good IOC container should remain iinvisible to programmers. They only design their component in a IOC pattern. How these coponents are assembled is not their business.


You are comparing apples and oranges.
IOC design means the object is passed to you rather than you explicitly create it via "new" or some other way.

IOC:

class IOC{
  private final A a;
  IOC(A a);{this.a = a;}
}

new:

class NewC{
  private final A a = new AImpl();;
  NewC();{}
}

These two are competitors. IOC container is just an optional tool only when you deside to use IOC instead of explicit "new".


I agree with you. And that's why a good IOC container should remain non-intrusive so that those programmers do _not_ need to know it at all.

I guess neither you nor your leader understand IOC. IOC is not supposed to make your job harder. It is a tiny, little, simple, vanilla pattern where you can assume everything you need will be passed to you. Can things be ever simpler?




Again, IOC and "IOC container" are two different concepts. Don't be confused.