Smart Framework：轻量级 Java Web 框架
工作闲暇之余，我开发了一款轻量级 Java Web 框架 —— Smart Framework。 开发该框架是为了： 加速基于 Java 的中小型 Web 应用程序的开发，让开发人员将更多的精力集中到业务上，而无需过多地关心底层技术细节。 推广国内开源事业的发展，吸引更多有想法并且有开源奉献精神的朋友，一起共同探讨，并分享自己的经验。 ...
作者: 黄勇
{{emojiItem.symbol}}
推荐博客
PAI Model Gallery 支持云上一键部署 Qwen3 全尺寸模型
阿里云大数据AI技术 · 昨天 13:24
删除一条评论
评论删除后，数据将无法恢复
引用来自“zhangwdcdd”的评论
书本里面和代码里面没有什么测试代码 写完一个功能点 都是懵的 这点做得太不好了
引用来自“祖大俊”的评论
黄先生，“微小的内核，灵活的插件”的图，是用什么工具画的？引用来自“JackFace”的评论
楼主，群满员了！引用来自“王仁辉(java)”的评论
求评价 我的restful的框架 model和jfinal一样是activerecord的设计 route更简洁一些https://github.comDreampie/resty
https://github.comDreampie/resty
使用 Smart Security 实现安全控制
http://my.oschina.net/huangyong/blog/214927
引用来自“孤独的3”的评论
比较喜欢第1点，第4点也很赞，这是未来的趋势...
楼主可以参考下@JFinal
波总的很多观念和楼主的类似，哈哈...
引用来自“腾勇”的评论
完全依赖于ajax 不太适合互联网应用，互联网应用需要被搜索引擎收录。二完全ajax，会增加http请求数
引用来自“openwsn”的评论
Excellent work
但spring本身也在演化当中，今天所考虑的这些问题，很多即将被新版本spring所支持和实现。能否站在未来的Internet应用所需的软件架构角度，审视下一代Internet应用所需框架的设计思路，做一个理念和思路上的提升？
引用来自“韶华”的评论
博主你的smart-framework在maven里找不到依赖了。
http://maven.oschina.net/index.html#nexus-search;quick~smart framework
引用来自“edit”的评论
servlet3.0 注解 里 servlet的拦截 顺序 是怎样的？ 假如 多个filter 或者 多个servlet 会不会出现问题？ 看到web.xml 0语句很诧异，注解 对维护什么的 不清晰，配置文件 可以很容易理清脉络吧
向大牛学习
引用来自“沫小依”的评论
lz写得不错~支持一下~时刻关注你的更新~
引用来自“黄勇”的评论
@zoujianfang 建议将页面跳转通过配置文件进行管理，并且这个配置文件可以通过代码生成器来创建。这个思路有些意思，所以也想听听其他朋友们的建议。
此外，我正在思考如何将非核心功能做成 Plugin 的形式，供用户使用。比如：邮件发送、Web 服务、消息驱动等。也请朋友们多给点建议，是否应该这样去做？应该怎样去做？
引用来自“黄开源中国”的评论
引用来自“黄勇”的评论
引用来自“爪哇老妖”的评论
看了上面的几点，略有感触，感觉楼主有种大包大揽的趋势，框架问世本应该是开放的，不能使用Spring，但可以支持Spring无缝集成，不使用Jsp但可以支持Jsp，业界有很多不错模板引擎，如Freemark、Velocity等，他们一直致力于前端与后台分离，关于Ajax与后端交互是一个趋势，但交互得需要规范，否则是无法并行开发的，能否分离就看规范的定义了。关于Spring容器的初始化，吸其长处，避其短处，框架不应该是再造轮子，但可以改进轮子。
引用来自“路小磊”的评论
把评论从头到尾看到了一遍，感触很深啊。我现在的一个项目也是在Servlet3的基础上做了一个很烂的框架，开始的目的很明确，项目很小，用SSH感觉太重量了，后来自己的框架缺乏灵活性，又改啊该，发现缺少扩展性，再改啊改，最后自己的代码自己都看着恶心，所谓鱼与熊掌不可兼得，有些理念其实相互冲突的（解耦、扩展性、易用性、快速开发），要想实现灵活，就要牺牲一些易用性，所以建议楼主可以先用用楼上各位提及的框架，自己权衡哪些可以抛弃，哪些可以学习吸取，然后开始行动。
顺便说一句，我很厌恶那些不五毛党，你都不说理由，上来就是一通对博主的讽刺，有意思么。
或许我们觉得 SSH 过于重量是因为在漫长的 项目维护期我们并没有遇到那么多问题才感觉到 SSH 繁重。
http://git.oschina.net/huangyong/smart-framework
期待大家的 Pull Requests 与 Issues！
类：com.smart.framework.helper.SQLHelper
方法：generateInsertSQL、generateUpdateSQL
这两个方法里面有段代码：
StringBuilder columns = new StringBuilder(" ");
StringBuilder values = new StringBuilder(" values ");
for (Map.Entry<String, ?> fieldEntry : fieldMap.entrySet()) {
String columnName = StringUtil.toUnderline(fieldEntry.getKey());
Object columnValue = fieldEntry.getValue();
if (i == 0) {
columns.append("(").append(columnName);
values.append("('").append(columnValue).append("'");
} else if (i == fieldMap.size() - 1) {
columns.append(", ").append(columnName).append(")");
values.append(", '").append(columnValue).append("')");
} else {
columns.append(", ").append(columnName);
values.append(", '").append(columnValue).append("'");
}
i++;
}
sql.append(columns).append(values);
这里没有做字段的类型判断，而是统统默认使用string类型。并且存在sql注入问题
还有构造的select的sql用的是select *，dbutils只是原封不动的执行sql语句，所以最终这个*还是交给了数据库解析
例如opencms 是发展思路就很清晰 明确，就把jsp xml 耍得很熟练，一直坚持发展到现在
此外，我正在思考如何将非核心功能做成 Plugin 的形式，供用户使用。比如：邮件发送、Web 服务、消息驱动等。也请朋友们多给点建议，是否应该这样去做？应该怎样去做？
引用来自“zoujianfang”的评论
引用来自“黄勇”的评论
感谢楼上朋友们的建议，现在已将 Maven 修改为 Java 1.6 编译。
@zoujianfang @贤者以其昭昭
引用来自“式地要”的评论
啥时候把定时任务也封装一下哈
引用来自“贤者以其昭昭”的评论
对于smart-sample 建议 直接使用jetty吧！ 在eclipse环境中 采用maven构建 jetty 更方便 ！
@zoujianfang @贤者以其昭昭
引用来自“zoujianfang”的评论
老黄项目导入高定了，先GIT导入到本地库，只建立库不建立项目，然后用MAVEN方式导入为项目，有个小小的建议，POM早点修改为JAVA 6以上版本吧
引用来自“pwqok”的评论
终于发布了，等很久了，在看源码…不知是否有计划加入权限部分的功能？
引用来自“linan”的评论
@黄勇 简单看了下代码， 不支持blob,clob？
引用来自“陈春伟”的评论
总体来说还是造了很多重复的轮子。而且作为framework其实尽量的不约束各个模块使用的具体技术形式。而得供流程及工作具的作用。总体来说你描术的几点都在约束一些技术实现。比如标、比如前后端的分离方式。当然我不太清楚其它的方式是否支持，但一种方式是没法满足用户的需求的。作为一个普及的框架，好用的框架，每个模块的灵活性非常重要，当然作为自用框架，本着减 少重复编码作为第一考虑要素就好。不过楼主是想做成通用框架。那这个方向其实注定它是不能普遍被接受的。注解是趁势。但是支持xml配置是一种需求。趋势不能代表需求。xml配置和注解配置是针对不同的业务场景的。xml可以让其它的应用参考配置，动态的修改配置 ，这种修改可以是人工或是跨平台的。而注释注定在jvm范畴的，总体支持楼主的尝试，但还是沷些冷水。
引用来自“黄勇”的评论
引用来自“唐阳”的评论
不适合seo啊
引用来自“黄勇”的评论
引用来自“唐阳”的评论
不适合seo啊
引用来自“唐阳”的评论
不适合seo啊
引用来自“ToB蓝波湾”的评论
看了好多评论，突然觉得，要想做什么就去做吧，不要在乎别人说什么，否则你将寸步难行
引用来自“屁屁果”的评论
引用来自“路小磊”的评论
把评论从头到尾看到了一遍，感触很深啊。我现在的一个项目也是在Servlet3的基础上做了一个很烂的框架，开始的目的很明确，项目很小，用SSH感觉太重量了，后来自己的框架缺乏灵活性，又改啊该，发现缺少扩展性，再改啊改，最后自己的代码自己都看着恶心，所谓鱼与熊掌不可兼得，有些理念其实相互冲突的（解耦、扩展性、易用性、快速开发），要想实现灵活，就要牺牲一些易用性，所以建议楼主可以先用用楼上各位提及的框架，自己权衡哪些可以抛弃，哪些可以学习吸取，然后开始行动。
顺便说一句，我很厌恶那些不五毛党，你都不说理由，上来就是一通对博主的讽刺，有意思么。
引用来自“路小磊”的评论
把评论从头到尾看到了一遍，感触很深啊。我现在的一个项目也是在Servlet3的基础上做了一个很烂的框架，开始的目的很明确，项目很小，用SSH感觉太重量了，后来自己的框架缺乏灵活性，又改啊该，发现缺少扩展性，再改啊改，最后自己的代码自己都看着恶心，所谓鱼与熊掌不可兼得，有些理念其实相互冲突的（解耦、扩展性、易用性、快速开发），要想实现灵活，就要牺牲一些易用性，所以建议楼主可以先用用楼上各位提及的框架，自己权衡哪些可以抛弃，哪些可以学习吸取，然后开始行动。
顺便说一句，我很厌恶那些不五毛党，你都不说理由，上来就是一通对博主的讽刺，有意思么。
引用来自“路小磊”的评论
把评论从头到尾看到了一遍，感触很深啊。我现在的一个项目也是在Servlet3的基础上做了一个很烂的框架，开始的目的很明确，项目很小，用SSH感觉太重量了，后来自己的框架缺乏灵活性，又改啊该，发现缺少扩展性，再改啊改，最后自己的代码自己都看着恶心，所谓鱼与熊掌不可兼得，有些理念其实相互冲突的（解耦、扩展性、易用性、快速开发），要想实现灵活，就要牺牲一些易用性，所以建议楼主可以先用用楼上各位提及的框架，自己权衡哪些可以抛弃，哪些可以学习吸取，然后开始行动。
顺便说一句，我很厌恶那些不五毛党，你都不说理由，上来就是一通对博主的讽刺，有意思么。
顺便说一句，我很厌恶那些不五毛党，你都不说理由，上来就是一通对博主的讽刺，有意思么。
引用来自“AlbertJun”的评论
引用来自“黄勇”的评论
引用来自“AlbertJun”的评论
引用来自“黄勇”的评论
引用来自“铂金小熊”的评论
第6点我比较喜欢，第4条的话我倒是不推荐，個人比较喜欢纯粹的HTML页面展示效果。
引用来自“AlbertJun”的评论
引用来自“黄勇”的评论
引用来自“铂金小熊”的评论
第6点我比较喜欢，第4条的话我倒是不推荐，個人比较喜欢纯粹的HTML页面展示效果。
引用来自“Jack王传杰”的评论
又一个技术理想主义者，做为自己学习研究，分享开源到还可以。个人感觉不如花时间真正掌握spring这些框架的核心技术点 ，达到庖丁解牛的程度，这样才能真正有提高，更能领会开源的精神。
引用来自“熊二”的评论
引用来自“黄勇”的评论
引用来自“savior-guo”的评论
引用来自“烈冰”的评论
就相当于你自己再做一个spring和hibernate，作为研究还可以，但实际应用的话意义不大
引用来自“savior-guo”的评论
引用来自“烈冰”的评论
就相当于你自己再做一个spring和hibernate，作为研究还可以，但实际应用的话意义不大
引用来自“伊万”的评论
认为使用纯HTML+ajax的方式不比jsp方便。
1、美工和程序员本来就可以并行工作，程序员在没有拿到美工的页面前，专注于做业务相关开发，前端顶多就是比较丑陋而已，然后，拿到美工页面再做修改。
2、纯粹使用ajax获取数据，然后做渲染，会相当累人。想想看，如果一个大表单（比如100个表单控件），光填充值这一块的js代码就会不堪入目。jsp使用el就搞定了。
引用来自“sahala232”的评论
引用来自“红四团”的评论
引用来自“黄勇”的评论
引用来自“铂金小熊”的评论
第6点我比较喜欢，第4条的话我倒是不推荐，個人比较喜欢纯粹的HTML页面展示效果。
引用来自“sahala232”的评论
你这个方案如何实现文件的上传和下载呢？
引用来自“红四团”的评论
引用来自“黄勇”的评论
引用来自“铂金小熊”的评论
第6点我比较喜欢，第4条的话我倒是不推荐，個人比较喜欢纯粹的HTML页面展示效果。
引用来自“哈库纳”的评论
引用来自“JFinal”的评论
引用来自“南湖船老大”的评论
楼主的想法我基本都赞同。。不能使用有点绝对了，应该是继续支持JSP和spring，提供接口进行扩展，一刀断不好。
还有按目前的形势看，你这个框架几乎没办法推广。jfinal够简单了吧，推广都那么难。因为框架简单了，反过来，人要做的事情就复杂了
所以我觉得类似JFinal这类简单的框架在某一个领域内应用绝对不会面对复杂的事情，如果出现这种情况一定是应用领域超过了最初设计目标。
我觉得JFinal如果继续走目前急速Web开发的道路不会遇到太多的问题，只需要完善好当前API适当引入新特性就好，这意味着JFinal可能要放弃一些东西。
但是开发人员不会就这么罢休的，他们会尝试扩展这类简单框架使其应用领域进一步扩大。我想@湖南船老大 想说的就是这个，开发人员会用尽脑汁扩展简单框架以达到复杂场景应用的目的。这样以来就会造成“人做的事就复杂了”。
引用来自“JFinal”的评论
引用来自“南湖船老大”的评论
楼主的想法我基本都赞同。。不能使用有点绝对了，应该是继续支持JSP和spring，提供接口进行扩展，一刀断不好。
还有按目前的形势看，你这个框架几乎没办法推广。jfinal够简单了吧，推广都那么难。因为框架简单了，反过来，人要做的事情就复杂了
所以我觉得类似JFinal这类简单的框架在某一个领域内应用绝对不会面对复杂的事情，如果出现这种情况一定是应用领域超过了最初设计目标。
我觉得JFinal如果继续走目前急速Web开发的道路不会遇到太多的问题，只需要完善好当前API适当引入新特性就好，这意味着JFinal可能要放弃一些东西。
但是开发人员不会就这么罢休的，他们会尝试扩展这类简单框架使其应用领域进一步扩大。我想@湖南船老大 想说的就是这个，开发人员会用尽脑汁扩展简单框架以达到复杂场景应用的目的。这样以来就会造成“人做的事就复杂了”。
引用来自“Phnix”的评论
引用来自“黄勇”的评论
引用来自“腾勇”的评论
完全依赖于ajax 不太适合互联网应用，互联网应用需要被搜索引擎收录。二完全ajax，会增加http请求数
引用来自“Phnix”的评论
lz这个框架已经开始写了吗？看了这么多评论，收获很大。虽然是开源框架，但第一个版本，肯定是作者自己完全来写了。等有了原型后，后续才会有人加入进来。
引用来自“charles_wang”的评论
引用来自“luokery”的评论
引用来自“黄勇”的评论
引用来自“铂金小熊”的评论
第6点我比较喜欢，第4条的话我倒是不推荐，個人比较喜欢纯粹的HTML页面展示效果。
引用来自“腾勇”的评论
完全依赖于ajax 不太适合互联网应用，互联网应用需要被搜索引擎收录。二完全ajax，会增加http请求数
引用来自“hsxy8”的评论
能写框架啊，写出来再说，你技术这么牛逼也不行，做技术的改不了高傲的特性，
引用来自“ROBOCOP”的评论
@黄勇 看了你对轻量级 JavaEE 框架设计思想，特别是提出的那几点框架技术需求，让我突然有点小激动，因为我也有和你一样想法，初衷只是想按自己的编码习惯，尽量采用最简单的方式实现我需要的东西，与你提出的技术需求基本一致，项目地址：http://url.cn/HmaKCO，希望一起交流完善~！
引用来自“黄勇”的评论
引用来自“哈库纳”的评论
引用来自“黄勇”的评论
引用来自“哈库纳”的评论
我觉得在设计一款框架之前不能以取代谁作为目标。这个世上还没有什么事物可以被取代，这不符合哲学。
其次我觉得，项目启动慢一点还可以接受，如果框架支持类文件改变动态加载更新就像tomcat一样就是启动时间在5分钟调试时候不需要反复重启的设计就很棒。
还有我也觉得spring现在也越来越臃肿了，guice还比较不错。我在设计hasor时候就选择的它作为DI容器。
其实我觉得一个好的架构应该是贴近开发者，便于部署维护的，API简单易懂就好，不知道楼主感觉怎么样？
对于guice来说对象的依赖也是当创建时候才去加载。性能上非常不错。是一款可以替代spring的另外一个选择。
我比较喜欢guice主要除了轻量之外，是因为它还有一个绑定操作。绑定这个过程实在是太好用。具体用法我可以和你另外探讨
互联网Web项目和 管理类Web项目 对视图层的设计是完全不一样的。可以说用两套架构体系去 描述都不为过。
MVC还是比较经典的，你说的过时我觉得不存在，可以把MVC的形式变版一下，在视图层中直接调用模型层取得数据。的做法就非常非常的爽。 既保留MVC模式又增加编程灵活性。
还有就是美工和后台双线开发，我以前搞过这块不是新鲜事务。关键要掌控好项目的模块拆解和调用接口的设计。
引用来自“哈库纳”的评论
引用来自“黄勇”的评论
引用来自“哈库纳”的评论
我觉得在设计一款框架之前不能以取代谁作为目标。这个世上还没有什么事物可以被取代，这不符合哲学。
其次我觉得，项目启动慢一点还可以接受，如果框架支持类文件改变动态加载更新就像tomcat一样就是启动时间在5分钟调试时候不需要反复重启的设计就很棒。
还有我也觉得spring现在也越来越臃肿了，guice还比较不错。我在设计hasor时候就选择的它作为DI容器。
其实我觉得一个好的架构应该是贴近开发者，便于部署维护的，API简单易懂就好，不知道楼主感觉怎么样？
对于guice来说对象的依赖也是当创建时候才去加载。性能上非常不错。是一款可以替代spring的另外一个选择。
我比较喜欢guice主要除了轻量之外，是因为它还有一个绑定操作。绑定这个过程实在是太好用。具体用法我可以和你另外探讨
引用来自“黄勇”的评论
引用来自“哈库纳”的评论
我觉得在设计一款框架之前不能以取代谁作为目标。这个世上还没有什么事物可以被取代，这不符合哲学。
其次我觉得，项目启动慢一点还可以接受，如果框架支持类文件改变动态加载更新就像tomcat一样就是启动时间在5分钟调试时候不需要反复重启的设计就很棒。
还有我也觉得spring现在也越来越臃肿了，guice还比较不错。我在设计hasor时候就选择的它作为DI容器。
其实我觉得一个好的架构应该是贴近开发者，便于部署维护的，API简单易懂就好，不知道楼主感觉怎么样？
对于guice来说对象的依赖也是当创建时候才去加载。性能上非常不错。是一款可以替代spring的另外一个选择。
我比较喜欢guice主要除了轻量之外，是因为它还有一个绑定操作。绑定这个过程实在是太好用。具体用法我可以和你另外探讨
引用来自“ForEleven”的评论
引用来自“哈库纳”的评论
引用来自“ForEleven”的评论
如果你是想做了，然后在公司里面使用的话。作为一个站在普通程序员的角度来看，对这个是很反感的。不利于员工的发展，换工作的时候会有很大的阻碍。
不知道你们做什么样的项目，需要自己重构框架，Spring已经很成熟，开发速度不见得比你重新做一个来得慢。框架永远不是系统性能的瓶颈，所以如果想作为公司里面用，表示不支持。
如果只是想做一个开源的东西，那表示支持，不过不看好，JEE框架感觉已经走到头了。这是个人看法。
还要考虑的是跟其他一些东西的集成是否方便，OAuth2，单点登录什么的，毕竟Spring对这些的集成方案很成熟，自己搞的框架开发，维护都是成本。
项目的进度，系统的性能往往都不是框架技术的问题。在项目经验上的累积，才是提供公司效益最有效的途径。这有点扯远了，只是看楼主的意思是想在公司内部用，有点觉得不太支持罢了。
引用来自“哈库纳”的评论
我觉得在设计一款框架之前不能以取代谁作为目标。这个世上还没有什么事物可以被取代，这不符合哲学。
其次我觉得，项目启动慢一点还可以接受，如果框架支持类文件改变动态加载更新就像tomcat一样就是启动时间在5分钟调试时候不需要反复重启的设计就很棒。
还有我也觉得spring现在也越来越臃肿了，guice还比较不错。我在设计hasor时候就选择的它作为DI容器。
其实我觉得一个好的架构应该是贴近开发者，便于部署维护的，API简单易懂就好，不知道楼主感觉怎么样？
引用来自“抓瓦工人”的评论
个人觉得,如果参与人员都水平差不多,那还可行,如果都是北鸟那种,那可不好!
引用来自“ForEleven”的评论
引用来自“哈库纳”的评论
引用来自“ForEleven”的评论
如果你是想做了，然后在公司里面使用的话。作为一个站在普通程序员的角度来看，对这个是很反感的。不利于员工的发展，换工作的时候会有很大的阻碍。
不知道你们做什么样的项目，需要自己重构框架，Spring已经很成熟，开发速度不见得比你重新做一个来得慢。框架永远不是系统性能的瓶颈，所以如果想作为公司里面用，表示不支持。
如果只是想做一个开源的东西，那表示支持，不过不看好，JEE框架感觉已经走到头了。这是个人看法。
还要考虑的是跟其他一些东西的集成是否方便，OAuth2，单点登录什么的，毕竟Spring对这些的集成方案很成熟，自己搞的框架开发，维护都是成本。
项目的进度，系统的性能往往都不是框架技术的问题。在项目经验上的累积，才是提供公司效益最有效的途径。这有点扯远了，只是看楼主的意思是想在公司内部用，有点觉得不太支持罢了。
用外面现成的东西一直一来都有一个弊端，就是你永远不知道里面有什么陷阱在等着你，如果遇到一个框架无法解决的难题更是苦不堪言。不过还好遇到这种事情的概率根买彩票差不多。
引用来自“哈库纳”的评论
引用来自“ForEleven”的评论
如果你是想做了，然后在公司里面使用的话。作为一个站在普通程序员的角度来看，对这个是很反感的。不利于员工的发展，换工作的时候会有很大的阻碍。
不知道你们做什么样的项目，需要自己重构框架，Spring已经很成熟，开发速度不见得比你重新做一个来得慢。框架永远不是系统性能的瓶颈，所以如果想作为公司里面用，表示不支持。
如果只是想做一个开源的东西，那表示支持，不过不看好，JEE框架感觉已经走到头了。这是个人看法。
还要考虑的是跟其他一些东西的集成是否方便，OAuth2，单点登录什么的，毕竟Spring对这些的集成方案很成熟，自己搞的框架开发，维护都是成本。
项目的进度，系统的性能往往都不是框架技术的问题。在项目经验上的累积，才是提供公司效益最有效的途径。这有点扯远了，只是看楼主的意思是想在公司内部用，有点觉得不太支持罢了。
引用来自“ForEleven”的评论
如果你是想做了，然后在公司里面使用的话。作为一个站在普通程序员的角度来看，对这个是很反感的。不利于员工的发展，换工作的时候会有很大的阻碍。
不知道你们做什么样的项目，需要自己重构框架，Spring已经很成熟，开发速度不见得比你重新做一个来得慢。框架永远不是系统性能的瓶颈，所以如果想作为公司里面用，表示不支持。
如果只是想做一个开源的东西，那表示支持，不过不看好，JEE框架感觉已经走到头了。这是个人看法。
不知道你们做什么样的项目，需要自己重构框架，Spring已经很成熟，开发速度不见得比你重新做一个来得慢。框架永远不是系统性能的瓶颈，所以如果想作为公司里面用，表示不支持。
如果只是想做一个开源的东西，那表示支持，不过不看好，JEE框架感觉已经走到头了。这是个人看法。
其次我觉得，项目启动慢一点还可以接受，如果框架支持类文件改变动态加载更新就像tomcat一样就是启动时间在5分钟调试时候不需要反复重启的设计就很棒。
还有我也觉得spring现在也越来越臃肿了，guice还比较不错。我在设计hasor时候就选择的它作为DI容器。
其实我觉得一个好的架构应该是贴近开发者，便于部署维护的，API简单易懂就好，不知道楼主感觉怎么样？
引用来自“抓瓦工人”的评论
条件到是不错,不过成熟估计猴年马月了,如果你觉得java有危你初衷,你可以考虑其他给予jvm的语言,比如 scala,或者你看看play 怎么样,符合你要求吗!
引用来自“南湖船老大”的评论
楼主的想法我基本都赞同。。不能使用有点绝对了，应该是继续支持JSP和spring，提供接口进行扩展，一刀断不好。
还有按目前的形势看，你这个框架几乎没办法推广。jfinal够简单了吧，推广都那么难。因为框架简单了，反过来，人要做的事情就复杂了
引用来自“南湖船老大”的评论
楼主的想法我基本都赞同。。不能使用有点绝对了，应该是继续支持JSP和spring，提供接口进行扩展，一刀断不好。
还有按目前的形势看，你这个框架几乎没办法推广。jfinal够简单了吧，推广都那么难。因为框架简单了，反过来，人要做的事情就复杂了
还有按目前的形势看，你这个框架几乎没办法推广。jfinal够简单了吧，推广都那么难。因为框架简单了，反过来，人要做的事情就复杂了
引用来自“黄勇”的评论
引用来自“Dead_knight”的评论
说实话，目前所谓的java ee基础开发平台遍地开花，到处都是，我也是曾经的参与者，现在回过头来看看，综合各种因素考虑，实际上不仅没有提高太多的效率，反而增加了不少的成本。
如果是小项目，随便用什么主流框架整一整，都不成问题。
如果是团队项目，是不是还要考虑学习成本，团队协作呢？如果用主流的框架struts、spring、hibernate，招个新人过来，只要熟悉一点，立马能干活。如果用所谓的基础开发平台，还要对新人培训，而且需要保证基础开发平台的稳定性、容错性……这样的成本都考虑进来的话，就有点不值得了，如果是大公司，不在乎那样的成本，那当我没说。
引用来自“Dead_knight”的评论
说实话，目前所谓的java ee基础开发平台遍地开花，到处都是，我也是曾经的参与者，现在回过头来看看，综合各种因素考虑，实际上不仅没有提高太多的效率，反而增加了不少的成本。
如果是小项目，随便用什么主流框架整一整，都不成问题。
如果是团队项目，是不是还要考虑学习成本，团队协作呢？如果用主流的框架struts、spring、hibernate，招个新人过来，只要熟悉一点，立马能干活。如果用所谓的基础开发平台，还要对新人培训，而且需要保证基础开发平台的稳定性、容错性……这样的成本都考虑进来的话，就有点不值得了，如果是大公司，不在乎那样的成本，那当我没说。
如果是小项目，随便用什么主流框架整一整，都不成问题。
如果是团队项目，是不是还要考虑学习成本，团队协作呢？如果用主流的框架struts、spring、hibernate，招个新人过来，只要熟悉一点，立马能干活。如果用所谓的基础开发平台，还要对新人培训，而且需要保证基础开发平台的稳定性、容错性……这样的成本都考虑进来的话，就有点不值得了，如果是大公司，不在乎那样的成本，那当我没说。
引用来自“ruanzy”的评论
就第四点，我有过尝试，如果全部采用html+ajax 当页面要请求的数据较多时，页面会很慢，个人觉得jsp（可以充分利用EL）+ ajax 比较好
引用来自“勇往直前_2013”的评论
这个想法和12306的网站有点一样。
引用来自“黄勇”的评论
引用来自“打杂程序猿”的评论
.直接通过 AJAX 技术从服务端去获取数据，不再是传统的 MVC 模式，个人认为 MVC 模式已经有些过时了。
....该怎么吐槽你呢....这个还不是mvc的核心........只是把后端做成了m层..vc层在前端处理而已....核心还是那套..除非你想说MVVM等... .........再说了mvc 那里来的什么传统不传统的一说,只有不同实现而已........同样,也没有什么过不过时一说..
引用来自“黄文祥”的评论
我觉得项目在开发启动的时候也不是每次都要启动的，添加新的功能肯定要启动但也会需要很久，不过也不知道楼主说到项目有多大需要等这么久？或是开发机器配置确实不给力吧！不过也一直想整理个开发效率高的框架只注重业务就行，但一直忙于每天的代码确实没那个精力
引用来自“huhu”的评论
呵呵，作为项目经理最抓狂的不是新的，而是稳定与简单的。
引用来自“searchjack”的评论
en , 请关注 JFinal
引用来自“打杂程序猿”的评论
.直接通过 AJAX 技术从服务端去获取数据，不再是传统的 MVC 模式，个人认为 MVC 模式已经有些过时了。
....该怎么吐槽你呢....这个还不是mvc的核心........只是把后端做成了m层..vc层在前端处理而已....核心还是那套..除非你想说MVVM等... .........再说了mvc 那里来的什么传统不传统的一说,只有不同实现而已........同样,也没有什么过不过时一说..
....该怎么吐槽你呢....这个还不是mvc的核心........只是把后端做成了m层..vc层在前端处理而已....核心还是那套..除非你想说MVVM等... .........再说了mvc 那里来的什么传统不传统的一说,只有不同实现而已........同样,也没有什么过不过时一说..
引用来自“爪哇老妖”的评论
看了上面的几点，略有感触，感觉楼主有种大包大揽的趋势，框架问世本应该是开放的，不能使用Spring，但可以支持Spring无缝集成，不使用Jsp但可以支持Jsp，业界有很多不错模板引擎，如Freemark、Velocity等，他们一直致力于前端与后台分离，关于Ajax与后端交互是一个趋势，但交互得需要规范，否则是无法并行开发的，能否分离就看规范的定义了。关于Spring容器的初始化，吸其长处，避其短处，框架不应该是再造轮子，但可以改进轮子。
引用来自“空云万里晴”的评论
不考虑支持AOP吗
引用来自“烈冰”的评论
就相当于你自己再做一个spring和hibernate，作为研究还可以，但实际应用的话意义不大
引用来自“爪哇老妖”的评论
看了上面的几点，略有感触，感觉楼主有种大包大揽的趋势，框架问世本应该是开放的，不能使用Spring，但可以支持Spring无缝集成，不使用Jsp但可以支持Jsp，业界有很多不错模板引擎，如Freemark、Velocity等，他们一直致力于前端与后台分离，关于Ajax与后端交互是一个趋势，但交互得需要规范，否则是无法并行开发的，能否分离就看规范的定义了。关于Spring容器的初始化，吸其长处，避其短处，框架不应该是再造轮子，但可以改进轮子。
引用来自“抓瓦工人”的评论
条件到是不错,不过成熟估计猴年马月了,如果你觉得java有危你初衷,你可以考虑其他给予jvm的语言,比如 scala,或者你看看play 怎么样,符合你要求吗!
楼主可以参考下@JFinal
波总的很多观念和楼主的类似，哈哈...
引用来自“黄勇”的评论
引用来自“屁屁果”的评论
引用来自“黄勇”的评论
引用来自“屁屁果”的评论
我实在是很难接收spring 越来越笨重……我的开源项目 springrain,除了第2点，其他的都实现了
引用来自“屁屁果”的评论
引用来自“黄勇”的评论
引用来自“屁屁果”的评论
我实在是很难接收spring 越来越笨重……我的开源项目 springrain,除了第2点，其他的都实现了
引用来自“黄勇”的评论
引用来自“屁屁果”的评论
我实在是很难接收spring 越来越笨重……我的开源项目 springrain,除了第2点，其他的都实现了
引用来自“黄勇”的评论
引用来自“屁屁果”的评论
我实在是很难接收spring 越来越笨重……我的开源项目 springrain,除了第2点，其他的都实现了
引用来自“屁屁果”的评论
我实在是很难接收spring 越来越笨重……我的开源项目 springrain,除了第2点，其他的都实现了
引用来自“铂金小熊”的评论
第6点我比较喜欢，第4条的话我倒是不推荐，個人比较喜欢纯粹的HTML页面展示效果。