来自保皇派的意见

   看到过太多的框架了，几乎每天我都能看到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是古希腊语，战神的意思。战神在神话中是宙斯与赫拉的儿子。他司职战争，形象英俊，性格强暴好斗，十分喜欢打仗，而且勇猛顽强，是力量与权力的象征，好斗与屠杀的战神。但他同时是嗜杀、血腥，人类灾祸的化身。

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

两点我都同意。只不过，我更激进，我直接把action干掉了。

这是demo的一些截图
文件目录结构



manager对象其中有通用查询getUserAll



action改动比较大真正做到无配置和约定大于配置(struts2的那个根本不是无配置说法，根据我的观察也没有发现多少约定大于配置的)

没有哪一层是必须的，根据项目大小需求可以任意组合，没有哪一个是通用的。

把事务做在action上，意味着每个请求都是一个事务，这个太死板。

每个方法这么多参数看着就累

根据业务情况，不写DAO层是很自然的，不用从框架层次刻意去掉那一层

如果把事物加在action上，那么还要service干吗？
直接所有代码写在action里得了。

这种设计不好

看了下代码，没什么新意。
而且将事务加在action上，那要service干嘛？

我不是这个意思，该写在哪一层的还是写在哪一层，只是对于有些简单的业务（save,update,find,count之类）就不需要加一个service、dao接口和实现类了，一个CommonDAO和一个BasicManager就通吃了。我有两个项目差不多都是这种情况，使用了JPA，除了CommonDAO没有加过其他DAO。
最极端的情况我见过的是action、service、dao都只要一个，只写页面html和sql，我用过，不爽。这种刻意而为的方式很不喜欢。

我看作者的意思，使用一个泛型DAO来取消DAO，本来就可以这样，为什么要改框架呢？
第二，事务加在action上，业务代码还是独立规划吧，复杂的话还要好好建模，否则以后业务模型变化或者规模增长你就会后悔了。如果仅仅是在action加入事务也未尝不可，但不能是强制性的