来自保皇派的意见

   看到过太多的框架了，几乎每天我都能看到javaeye上有人说自己的框架的事情。有些框架甚至完全号称要推翻SSH的技术栈，重写一个自己的世界。这里我不是想阻止大家做什么，而是来发表一下自己的反面意见，一个保皇派的意见。
   我曾经也非常疯狂的山寨过各种框架，我甚至预言SSH技术栈已经腐朽不堪一钱不值了，从mvc到aop，ioc，orm，我山寨过一系列的东西。最后我都是放弃了，理由很简单，最后我发现自己的东西越来越“像什么”，对没错。我已经没有了自己的创新而是在拼命的东拼西凑的堆积各种特性，不是一个特性的有机整合使用而是特性的大走秀。最后自然就没有那份心思做下去了。
    后来当我冷静之后仔细想想，我重新定位了自己是在做什么。我在做什么？我为什么要做这些呢？答案我找到了，我是想找到一个好用的工具，用这个工具来减轻自己的负担，仅此而已。既然如此那么我用什么手段又如何呢？我为什么要重写那些东西呢？它们真的不可救药了吗？
    我仔细研读了它们的代码之后对他们的作者只有赞叹了，而且他们的代码质量确实在不断地提升。既然如此我为什么不能借用这些代码来达到“自己省力”的目的呢？于是我开始收集各种好的实践，开始修改这些代码。它就形成了现在的ares，历经多次重写，多次整合。在多个项目中实际应用，终于我有勇气拿出来了。

项目站点
http://code.google.com/p/ares-project

下载
http://ares-project.googlecode.com/files/ares-1.0-ga.zip

在压缩包中有演示demo，只需要把hibernate.properties中的
hibernate.hbm2ddl.auto=validate
换成
hibernate.hbm2ddl.auto=update
就会自动帮你新建数据库了。当然别忘记修改用户名密码。

现在我要历数它的几大罪状，这些罪状会让一些人坐立不安和我争辩个面红耳赤。当然我只能说明自己的理由而不能说服你。

1. 取消DAO。
反对声音：违反分层，程序结构不明显等等
理由：通过统计我发现基本上所有的dao都是负责拼接SQL语句或者hql语句，基本上代码都是千篇一律的。所以有理由抽象出一个泛型DAO，提供通用dao方法来代替所有的dao对象。

2.事务加在action上
反对声音：绝对大逆不道，违反MVC分层，service层无法独立。
理由：说违反MVC分层我觉得这种说法的人首先不明白MVC，MVC指的是对web请求的一种处理方式，不是struts是v，spring是c hibernate是m，这种说法绝对是一种无稽之谈一种根本不懂MVC的无稽之谈。这种无稽之谈居然还出现在某些流行的书上。把事务加在service的理由是为了独立UI表现，以后甚至可以让桌面UI来调用这些service方法。但是实际情况往往不是这样，经常可以看到在action中有两个甚至三个service层的调用方法，归结原因是由于程序员在赶时间。如果还固守那老一套那么事务根本不在控制范围之内。action为什么不能加事务？找来找去找不到理由，通过阅读一些成熟的开源项目我更加坚定这种做法。这样做没错。百利而无一害。

上面两点是朋友提的最为“痛恨”的两点。当然还会有一些我等着大家继续拍板。
由于想赶在年前发布，时间仓促文档尚未整理完备。当然我更希望这些事情是由社区来做。呵呵。

备注：
ares是古希腊语，战神的意思。战神在神话中是宙斯与赫拉的儿子。他司职战争，形象英俊，性格强暴好斗，十分喜欢打仗，而且勇猛顽强，是力量与权力的象征，好斗与屠杀的战神。但他同时是嗜杀、血腥，人类灾祸的化身。

我取名战神是希望它能够不像以前一样夭折，而是越战越勇，去嗜血，去吸纳各种最佳实践。由于他是宙斯的儿子也意味着它是“继承”而不是“重写”。

没有看代码，不过想知道lz对下面问题是怎么解决的。
Action上加事物，如何进行测试业务逻辑？在web层会出现责任的混淆，每个类应该具有一个独立的清晰的责任。如果这样，action就有了两种不同的责任？业务对象会不会有serlet API的耦合？

我曾经也非常疯狂的山寨过各种框架，我甚至预言SSH技术栈已经腐朽不堪一钱不值了，从mvc到aop，ioc，orm，我山寨过一系列的东西。最后我都是放弃了，理由很简单，最后我发现自己的东西越来越“像什么”，对没错。我已经没有了自己的创新而是在拼命的东拼西凑的堆积各种特性，不是一个特性的有机整合使用而是特性的大走秀。最后自然就没有那份心思做下去了。