Yan Container beta 1 发布

Adding extension is fine. Pico has nano and many other extensions.
I just don't have enough time to work on those.

But, I have to say: "要学习一大堆概念" is not true. Programmers for business objects do _not_ need to know Yan at all!
They have nothing to learn.

Plus, an IOC container is not a replacement for factory.

True. IOC container can never beat factory on simplicity.
When a module needs a factory, use factory. One should not even think of an IOC container  in that case.

Allow me to quote my idol's words:
"Qiu Bu Shi Na Yang Ti Di". (Shao Lin Soccer)
:)



That's one big advantage Spring has over the pure IOC containers such as Pico or Yan.
I view Spring as a toolkit with almost everything for end-programmers. While Pico/Yan are more for embedding into more comprehensive frameworks.

One silly thought I have now is: if Pico can be successful, why can't Yan?

Who? Me?

I never asked any question about "IOC". It is such a simple idiom that I have been doing almost ever since, without knowing sombody bothered to give it a cool name later.

It was the people I asked who did not understand the concept of IOC and confused IOC and "IOC Container" together.


What I was asking was "What the heck is an IOC container?",
"Why do I need a container or whatever to do things as simple as IOC?".
"Why do I have to buy an expensive machine to help me chew gum?"

I was questioning "IOC Container", (and Yan is one of them), not IOC the simple idiom.

呵呵,话没有说清楚,IOC确实不是什么新概念，它是面向接口设计一种很自然的实现，robert martin老早就在C++ Report专栏的文章中做为oo design princle提出来了: The Dependency Inversion Principle，但当时却没几个人能确切地给IOC以及Container一个说明，以至于很多人都滥用IOC Container，你不是也在质疑为什么采用IOC Container而不遵守IOC的原则呢，所以我一直到现在都认为这是一个很明显地商业炒作，IOC这个名词之红火，连martin flower都跳出来打出自己的招牌: the Dependency Injection Pattern.

说实话，如果在项目中采用一个框架产品(例如Yan)，做为一个负责任的程序员又怎能不看一下产品具体的实现呢？我在你的code里看到了什么，monad??　the functional programming??　看完你和Trustno1开的关于fp讲座，我头都是昏的，你还说没什么可学的．

不过话又说回来了，越是让人看不懂的越是具有商业价值，况且现在还流行新瓶装旧酒，我看你是不是学一学业界的老大们炒作一把，回头你翻翻fp有关的理论文章，看有没有能吸引人眼球的名词，或者更狠些自己创造几个新名词出来，例如"monad超级函数组合器"之类，以后再介绍自己的作品时不管三七二十一先用这些名词把人砍晕了再说，这不比你在这里东施效颦地天天喊"Yan Container是目前中国水平最高的框架之一"强，而且显得＂层次＂更高.  

ennnnnnn.
Not exactly.

Are you gonna read EJB source code before using it? Jdk source code? JVM source code?  Yacc source code?

Whoever read Pico and Spring source code before using them, please raise your hand!


There are two groups of programmers.

1. programmers responsible for designing and implementing business logic. (in broader sense, including persistence, UI).

2. programmers responsible for assemblying components written in IOC pattern.



programmers in the first group should know nothing about IOC container. It is a shame if they have to know any API of a container.


programmers (or rather, assemblers) in the 2nd group do have to know the API. (unless there's a wrapper around the API, xml config file for example. But then they have to learn the xml syntax as well, don't think that's any easier)


Pico, Yan are targeted exclusively to the 2nd group of people.
Also, they are very friendly to be embedded into some more comprehensive framework.

They aren't called "micro-container" for nothing, right?

你说的这两类程序员确实存在，尤其是在项目开发前期，但在开发后期进入系统测试时，已经没法分的太清楚，出现的bug已不是单单理解业务逻辑就能解决的，更不要说在系统maintain时出现性能上的问题，别说要熟悉框架，有时连所采用的操作系统以及相关的辅助系统都要分析到．

这可能跟个人的经历和职业发展有关吧，我现在净干一些擦屁股的活，不熟悉整个系统，在限定时间内给客户解决问题，老板是要炒我鱿鱼的．

个人觉得你这个框架是不错的，如果不能推广应用就太可惜了，毕竟你已经有了个好的开端．如果能组织一个有经验的开发小组，比较系统地扩展产品的功能以及辅助的工具，能为项目提供一套比较完整地解决方案，才能成为真正有市场和发展前景的产品，不然也只是一套自己的玩具罢了.

我觉得熟悉整体框架的就是少数几个architect就可以了。一个大型系统指望所有程序员把所有技术都了解也不现实。

责任分工还是很重要的。当然，小型项目中，往往就是一两个人又当爹又当妈。
但是，即使如此，我也不认为你需要把所有你用到的open source都看通。（当然，我认为open source的使用还是要慎重的，不要太多piece）

至于这个框架的发展和推广，确实如你所说，只是我一个人扑腾是不够的。但是事情只能一步一步来。我个人的推广能力和鼓动能力都不够，确实亟需人才加盟啊。

看来T1的那个讲座是彻底失败了。唯一的作用就是让大家对monad望而却步。

其实很多东西都是，说穿了不过那么回事。大家觉得深奥，有时候是故弄玄虚，有时候就是讲解不得法。

其实你仔细看看那个Binder接口和bind函数，没那么难的。就是一个

Component bind(Object obj);


多简单的接口。也许我那个类不叫Monad反而会更方便你理解。

呃,对了,想最后问你一下你的license最后到底是怎么订的，我想把你的框架用.net实现一遍然后用在商务系统中在license上有什么问题没有,我懒得看那些法律上的条文了．  

bsd license.  Not sure exact detail. Should be fine with commercial use. but I guess you'll need to keep my copyright text in the source code if you modify the code.

1． 如果再发布的产品中包含源代码，则在源代码中必须带有原来代码中的BSD协议。
2． 如果再发布的只是二进制类库/软件，则需要在类库/软件的文档和版权声明中包含原来代码中的BSD协议。
3． 不可以用开源代码的作者/机构名字和原来产品的名字做市场推广。

BSD代码鼓励代码共享，但需要尊重代码作者的著作权。BSD由于允许使用者修改和重新发布代码，也允许使用或在BSD代码上开发商业软件发布和销售，因此是对商业集成很友好的协议。而很多的公司企业在选用开源产品的时候都首选BSD协议，因为可以完全控制这些第三方的代码，在必要的时候可以修改或者二次开发。

ROGER !!!