表现层框架、业务层框架、Tapestry VS Spring

Tapestry 的确有些类似struts 不过现在的tapestry4.02捆绑了Hivemind一起才能用，Hivemind做为Ioc容器 怎么说也可以算业务层了吧。那这种组合又算什么框架那？如果一这种组合跟Spring比较是否也就都属于业务层框架那？

业务层的理解：
模型+服务
其实业务层应该描述的是在需求分析中得到的所有一定领域的问题，把这些域问题通过建模，分解为模型+服务。hivemind可以把每个模型或服务完全再独立起来放到目录里，通过配置可在需要时在目录中寻找调用。这也就体现了Ioc的过人之处，使得设计非常灵活有些组件化的感觉。构建系统就像搭积木，这时你可以把所有的模型和服务统称为Service，你提供的Service的多少可以决定你的系统具备哪些功能。而这些Service就相当于积木实体，而Service之间的关联相当于积木怎么摆放，这就看你自己的想象力有多丰富，积木搭建的漂亮，说明你的业务层做得比较完善。

是的，其实Spring有Spring MVC，这属于表现层，现在这些框架都希望一统天线，最初的Tapestry3.0是表现层，而HiveMind是和JdonFramework一样的业务层Ioc框架，N年前我说Ioc容器将盛行天下，现在轻量框架的特征就是Ioc/DI。

HiveMind的Ioc和JdonFramework都是autowiring的，而Spring推荐使用是非autowiring，可能大家从非autowiring到autowiring有一个过程，很显然，在我的实践中，autowiring大大提高设计调试时间。

在设计调试时，大量类需要调整来调整去，A原来调用B，我想改成C调用B，那么只要将B接口代码转移到C中即可，autowiring将自动帮助配对，但是如果是非autowiring，那么这种调整，除了代码修改外，配置还需要，当然JDK5.0中使用元注释+配置可能会好些，但是无论如何，autowiring在搭积木时效率要高，特别是有几百个类时。

当我们可把业务层构件细分到类时，灵活性增强了，但是因为太细致，就需要autowiring帮助提高效率，否则过分注重细节也是很累人的。

HiveMind作为Ioc框架属于业务层，有个地方我不理解。如果不用hibernate只用JDBC作为持久层，那我将数据库查询的类（这应该属于持久层了吧）也作为Service注册到hivemind中，以便在业务应用中创建持久层的这个数据库查询类的对象，那么是不是可以说这个持久层对象将是由业务层创建的并由业务层使用？怎么我就有种感觉持久层的存在不清晰了。似乎属于业务层的范畴那。

>那我将数据库查询的类（这应该属于持久层了吧）也作为Service注册到hivemind中
是这样，都是POJO了，业务层和持久层的分层是设计，有时不能表现在代码上，Evans DDD对业务层继续分层：模型服务，我们也没有明显的代码区分标志，这是正常的，我们可以通过包名来区分。