IOC, huh?

所以这个才是spring/pico的优点。怎么被你说起来像是缺点了。而且，spring不仅仅是一个ioc容器。

不错，ironically，好的设计就是你需要给予最少关心的。

是它们的优点，但是如果你要利用好这个优点就最好保持对它们的无知。 桃李不言，下自成蹊。
:)

对了，说到生命期管理。哪位能给举个例子？我倒一时想不出来我有什么需要pico们给我做的，除了用xml配置文件定制系统。

有个疑问，举例说明吧
假设删除dept这个逻辑，删除dept以前，要把其下的employee全部删掉.(假设存储介质不是数据库,而是xml,无法使用级联删除).
现有两个接口
DeptDao和EmployeeDao
两个实现类
DeptDaoImpl和EmployeeDaoImpl
那么在DeptDao中要得到EmployeeDao如何得到呢?不需要ServiceLocator吗?
当然你可以自己组装一层,不直接调用spring,但道理好像一样的

Lifecycle:
http://www.picocontainer.org/Lifecycle
http://www.springframework.org/docs/reference/beans.html#beans-factory-lifecycle

实际用途:
设置一些默认值呀, 校验呀, 擦屁股呀等等, 比较适合偶这种想偷懒的人, 可以少写几行代码.

spring里面有一些现成的例子, 比如与hibernate, scheduling的整合等等.

真的有人不明白IoC就去用spring了, 该劈  , 偶在前面给的那个link, pico不是已经解释得很清楚了么???

spring的type2写法:

public interface DeptDAO {
    public void deleteDept(Dept dept);;
}

public class DeptDAOImpl implements DeptDAO{
    public void setEmployeeDAO(EmployeeDAO employeeDAO);{
        this.employeeDAO = employeeDAO;
    }

    public void deleteDept(Dept dept);{
        //remove dept node from xml tree
        ...
        employeeDAO.remove(dept.getEmployees(););;
    }
}

受教!
多谢

原以为自己懂,其实却不懂

在没有spring，pico出来之前，没有一个好的组装器，而自己的水准不够，写不出一个好的来，只好大量的使用factory模式。
现在有了这些，就可以放心大胆的使用起来了。可以这么说spring和pico极大的推动了ioc的普及。
现在发现spring是一个很好用的工具，已经遍布代码当中了，很难拆的出来了。

兄弟，其实还是不要用pico/spring来替代factory模式。
道理说不上来，感觉上有一点。如果大规模的取代factory的话，那个配置文件会非常难以管理。有时候配置上的错误也很难查。所以我的做法是在bean中注入factory，配置文件中搞定那些factory即可。
我现在渐渐的用groovy脚本来实现factory和对象组装的功能。道理也说不上来，纯粹的感觉。