Smart Framework:轻量级 Java Web 框架
博客专区 > 黄勇 的博客 > 博客详情
Smart Framework:轻量级 Java Web 框架
黄勇 发表于4年前
Smart Framework:轻量级 Java Web 框架
  • 发表于 4年前
  • 阅读 96447
  • 收藏 788
  • 点赞 126
  • 评论 210

工作闲暇之余,我开发了一款轻量级 Java Web 框架 —— Smart Framework


开发该框架是为了:

  1. 加速基于 Java 的中小型 Web 应用程序的开发,让开发人员将更多的精力集中到业务上,而无需过多地关心底层技术细节。

  2. 推广国内开源事业的发展,吸引更多有想法并且有开源奉献精神的朋友,一起共同探讨,并分享自己的经验。

  3. 对于个人而言,我想结交更多志同道合的朋友,将来有机会能够一起做点事情。


该框架有如下特点:

  1. 基于 Servlet 3.0 规范,可部署到 Tomcat 服务器中(或其他 Web 服务器)。

  2. 放弃 Spring、Hibernate 等日益加重的开发框架(同样也不考虑 EJB 3)。

  3. 采用“前后端分离”原则,即前端实现界面展现,后端实现业务逻辑。

  4. 客户端可通过 HTML + CSS + JS 展现界面,使用 AJAX 获取服务端数据并进行填充或渲染。

  5. 服务端可连接多种数据库,直接面向 SQL 语句,采取轻量级的 ORM 策略。

  6. 放弃 XML 配置,使用 Java 注解,并做到真正的“零配置”。

  7. 基于 REST 风格的 URL 编程规范,可对外发布 REST/SOAP Web 服务。

  8. 对配置性数据采用缓存机制,提供轻量级缓存工具。

  9. 应用基于面向服务编程(SOA 思想),可进行分布式部署。

  10. 灵活性高,便于定制与扩展。



项目源码 | 问题反馈 | 用户手册


我会和大家一起交流,共同设计这个框架,毫无保留地分享程序中每一行代码。随时更新,尽请关注!

有兴趣一起讨论的朋友,欢迎加入 QQ 群: 468396029120404320 (满)

非常感谢用您的宝贵时间来阅读本文,祝您生活愉快!


系列博文

  1. 对 Action 的初步构思(2013-09-01)

  2. 对 Entity 的初步构思(2013-09-01)

  3. 轻量级 Java Web 框架技术选型(2013-09-02)

  4. Action 分发机制实现原理(2013-09-03)

  5. Entity 映射机制实现原理(2013-09-03)

  6. 轻量级 Java Web 框架类图(2013-09-03)

  7. IOC 实现原理(2013-09-04)

  8. 用一个示例来说话(2013-09-04)

  9. 再来一个示例吧(2013-09-05)

  10. 事务管理实现原理(2013-09-07)

  11. 一个 CRUD 示例(2013-09-10)

  12. AOP 实现原理(2013-09-12)

  13. 对代码生成器的一点想法(2013-09-12)

  14. 实现文件上传(2013-09-17)

  15. 实现查询与分页(2013-09-17)

  16. 代码生成器实现过程(2013-09-17)

  17. 像这样做单元测试(2013-09-18)

  18. 封装 Servlet API(2013-09-20)

  19. 关于异常处理的解决方案(2013-09-23)

  20. 再论代码生成器(2013-10-12)

  21. 讨论 Smart Framework 2.0 功能特性(2013-10-16)

  22. 使用 Smart SDK 快速开发 Java Web 应用(2013-10-17)

  23. 两种 MVC 模式(2013-10-17)

  24. 支持“正向 MVC 模式”(2013-10-18)

  25. 使用“链式代理”实现 AOP(2013-10-22)

  26. Smart Plugin —— 从一个简单的 Cache 开始(2013-10-31)

  27. 访问安全控制解决方案(2013-11-03)

  28. 能否让 Cache 变得更加优雅?(2013-11-04)

  29. Cache Plugin 实现过程(2013-11-07)

  30. 一个简单的 Cache 淘汰策略(2013-11-19)

  31. 发布与调用 Web 服务还能再简化吗?(2013-11-22)

  32. 初步实现 WebService 插件(2013-11-22)

  33. 初步实现 Mail 插件 —— 发送邮件(2013-11-24)

  34. 初步实现 Mail 插件 —— 收取邮件(2013-11-25)

  35. 初步实现 I18N 插件(2013-11-26)

  36. 让 Smart WebService 插件支持 REST 服务(2013-11-29)

  37. 如何处理 WebService 中的 Map 对象?(2013-12-08)

  38. 关于文件上传的改进(2013-12-15)

  39. 初步实现 Job 插件(2013-12-15)

  40. 将 Hessian 集成到 Smart 中(2013-12-26)

  41. 共同编写 Smart 2.0 开发指南(2014-01-05)

  42. Smart 2.0 开发指南(2014-01-22)

  43. 让你的开发变得如此 Smart(2014-01-27)

  44. 从 Git@OSC 下载 Smart 源码(2014-02-05)

  45. 原来可以这样玩 SSO(2014-02-11)

  46. 单点登录解决方案 —— Smart SSO(2014-02-13)

  47. 使用 Smart Security 实现安全控制(2014-03-31)

  48. 对 Action 方法参数的改进方案(2014-04-01)

  49. 对 Smart 事务传播行为的一点想法(2014-04-18)

  50. Smart 项目进度与规划(2014-04-21)

  51. 将 Smart 构件发布到 Maven 中央仓库(2014-04-25)

  52. Smart 官网项目规划(2014-05-04)

  53. 对类扫描器的代码重构(2014-05-13)

  54. 让数据库连接池灵活配置(2014-05-14)

  55. 让数据访问更加自由(2014-05-15)

  56. 一个超轻量级的 ORM 框架(2014-05-19)

  57. 简单的重构让 MVC 的职责更加清晰(2014-05-20)

  58. Smart 功能总结(2014-06-06)

标签: Smart Java Web
共有 人打赏支持
黄勇
粉丝 5641
博文 114
码字总数 196279
作品 1
评论 (210)
苗哥
第6点我比较喜欢,第4条的话我倒是不推荐,個人比较喜欢纯粹的HTML页面展示效果。
光石头
我实在是很难接收spring 越来越笨重……我的开源项目 springrain,除了第2点,其他的都实现了
黄勇

引用来自“铂金小熊”的评论

第6点我比较喜欢,第4条的话我倒是不推荐,個人比较喜欢纯粹的HTML页面展示效果。

关于第4条,我想要表达的意思是:视图不要使用 JSP 开发,因为性能不会特别高,而且对于美工不太方便。我想要的开发模式是,美工在做页面设计的时候,架构师可以进行程序设计,这两个过程是并行的。随后,美工交付的是 HTML、CSS、JS 以及相关资源文件,程序员拿到之后,无需将 HTML 转为 JSP,而是直接通过 AJAX 技术从服务端去获取数据,不再是传统的 MVC 模式,个人认为 MVC 模式已经有些过时了。​
小人物_Amor
支持!关注中~
黄勇

引用来自“屁屁果”的评论

我实在是很难接收spring 越来越笨重……我的开源项目 springrain,除了第2点,其他的都实现了

关于第2点,我想也有必要解释一下。由于 Spring 管理的 Bean 越多,那么在 Spring 上下文初始化的时候就会越慢,一旦项目做大了,看看 Tomcat 的启动时间就知道了。更何况这样的等待时间,会让程序员的心情更加急躁。不错,Spring 3 已经做得很好了,可以减少 XML 配置,将工作转移到 Java 注解上了,这样解放了程序员,但是对整个框架付出了更多的牺牲,因为 Spring 需要在容器启动时一个个地去加载这些 Bean,时间比 XML 花得更多。同样,对于 Hibernate 这类 ORM 的看法,我也保持中立态度,性能确实不近人情,虽然写的代码少了,但系统也变慢了。
光石头

引用来自“黄勇”的评论

引用来自“屁屁果”的评论

我实在是很难接收spring 越来越笨重……我的开源项目 springrain,除了第2点,其他的都实现了

关于第2点,我想也有必要解释一下。由于 Spring 管理的 Bean 越多,那么在 Spring 上下文初始化的时候就会越慢,一旦项目做大了,看看 Tomcat 的启动时间就知道了。更何况这样的等待时间,会让程序员的心情更加急躁。不错,Spring 3 已经做得很好了,可以减少 XML 配置,将工作转移到 Java 注解上了,这样解放了程序员,但是对整个框架付出了更多的牺牲,因为 Spring 需要在容器启动时一个个地去加载这些 Bean,时间比 XML 花得更多。同样,对于 Hibernate 这类 ORM 的看法,我也保持中立态度,性能确实不近人情,虽然写的代码少了,但系统也变慢了。

我只用了spring,没有hibernate等其他框架。如果spring初始化加载bean启动会慢也是原因,单例bean带来的性能提升怎么算,ioc注入也便于扩展,开发环境springbean可以懒加载,这样启动就非常快了
光石头

引用来自“黄勇”的评论

引用来自“屁屁果”的评论

我实在是很难接收spring 越来越笨重……我的开源项目 springrain,除了第2点,其他的都实现了

关于第2点,我想也有必要解释一下。由于 Spring 管理的 Bean 越多,那么在 Spring 上下文初始化的时候就会越慢,一旦项目做大了,看看 Tomcat 的启动时间就知道了。更何况这样的等待时间,会让程序员的心情更加急躁。不错,Spring 3 已经做得很好了,可以减少 XML 配置,将工作转移到 Java 注解上了,这样解放了程序员,但是对整个框架付出了更多的牺牲,因为 Spring 需要在容器启动时一个个地去加载这些 Bean,时间比 XML 花得更多。同样,对于 Hibernate 这类 ORM 的看法,我也保持中立态度,性能确实不近人情,虽然写的代码少了,但系统也变慢了。

我是封装spring jdbc 实现的orm,性能可以达到java jdbc的极致
黄勇

引用来自“屁屁果”的评论

引用来自“黄勇”的评论

引用来自“屁屁果”的评论

我实在是很难接收spring 越来越笨重……我的开源项目 springrain,除了第2点,其他的都实现了

关于第2点,我想也有必要解释一下。由于 Spring 管理的 Bean 越多,那么在 Spring 上下文初始化的时候就会越慢,一旦项目做大了,看看 Tomcat 的启动时间就知道了。更何况这样的等待时间,会让程序员的心情更加急躁。不错,Spring 3 已经做得很好了,可以减少 XML 配置,将工作转移到 Java 注解上了,这样解放了程序员,但是对整个框架付出了更多的牺牲,因为 Spring 需要在容器启动时一个个地去加载这些 Bean,时间比 XML 花得更多。同样,对于 Hibernate 这类 ORM 的看法,我也保持中立态度,性能确实不近人情,虽然写的代码少了,但系统也变慢了。

我只用了spring,没有hibernate等其他框架。如果spring初始化加载bean启动会慢也是原因,单例bean带来的性能提升怎么算,ioc注入也便于扩展,开发环境springbean可以懒加载,这样启动就非常快了

你的建议非常好!但我有些顾虑,如果单例多了,也就意味着 JVM 中的 static 成员多了,那么对于 GC 就不太有利(永久代所需的内存会增大),虽然内存已经不值钱了,但是能够写出高性能的程序,这才是程序员的目标与要求。我对 Spring 非常情有独钟,它教会了我很多,IoC 和 AOP 是两个最优秀的设计。我们不妨学习一下 Spring 中这些优秀的技术思路,然后结合自身环境,打造一个适合自己团队的开发框架,我想这个才是我的初衷。
光石头

引用来自“黄勇”的评论

引用来自“屁屁果”的评论

引用来自“黄勇”的评论

引用来自“屁屁果”的评论

我实在是很难接收spring 越来越笨重……我的开源项目 springrain,除了第2点,其他的都实现了

关于第2点,我想也有必要解释一下。由于 Spring 管理的 Bean 越多,那么在 Spring 上下文初始化的时候就会越慢,一旦项目做大了,看看 Tomcat 的启动时间就知道了。更何况这样的等待时间,会让程序员的心情更加急躁。不错,Spring 3 已经做得很好了,可以减少 XML 配置,将工作转移到 Java 注解上了,这样解放了程序员,但是对整个框架付出了更多的牺牲,因为 Spring 需要在容器启动时一个个地去加载这些 Bean,时间比 XML 花得更多。同样,对于 Hibernate 这类 ORM 的看法,我也保持中立态度,性能确实不近人情,虽然写的代码少了,但系统也变慢了。

我只用了spring,没有hibernate等其他框架。如果spring初始化加载bean启动会慢也是原因,单例bean带来的性能提升怎么算,ioc注入也便于扩展,开发环境springbean可以懒加载,这样启动就非常快了

你的建议非常好!但我有些顾虑,如果单例多了,也就意味着 JVM 中的 static 成员多了,那么对于 GC 就不太有利(永久代所需的内存会增大),虽然内存已经不值钱了,但是能够写出高性能的程序,这才是程序员的目标与要求。我对 Spring 非常情有独钟,它教会了我很多,IoC 和 AOP 是两个最优秀的设计。我们不妨学习一下 Spring 中这些优秀的技术思路,然后结合自身环境,打造一个适合自己团队的开发框架,我想这个才是我的初衷。

你想的太多了,总强过疯狂的new吧,我以前也是自己封框架,最后明白,必须在流行通用框架上二次封装,不然私有框架的维护成本和培养成本远远超出你的想象。你可以下载试用下springrain,它是开发效率,性能,维护成本的三项综合
如梦技术
比较喜欢第1点,第4点也很赞,这是未来的趋势...
楼主可以参考下@JFinal
波总的很多观念和楼主的类似,哈哈...
-_-_-_-__
条件到是不错,不过成熟估计猴年马月了,如果你觉得java有危你初衷,你可以考虑其他给予jvm的语言,比如 scala,或者你看看play 怎么样,符合你要求吗!
黄勇

引用来自“抓瓦工人”的评论

条件到是不错,不过成熟估计猴年马月了,如果你觉得java有危你初衷,你可以考虑其他给予jvm的语言,比如 scala,或者你看看play 怎么样,符合你要求吗!

绝不敢说这个框架弄出来有多牛,主要是想借助现今比较适用的技术来提高一些开发质量与效率,受众群体首先应该是自己的团队吧,然后逐步向圈内进行推广,希望能够借助 OSC 平台,推广中国的开源事业。关于您所说的 Play 框架,我也研究过,这个基本上不再考虑范围之内了,因为个人认为学习成本有些高,属于门槛较低但爬坡陡峭的框架。非常感谢您的回复!
烈冰
就相当于你自己再做一个spring和hibernate,作为研究还可以,但实际应用的话意义不大
空云万里晴
不考虑支持AOP吗
陶邦仁
看了上面的几点,略有感触,感觉楼主有种大包大揽的趋势,框架问世本应该是开放的,不能使用Spring,但可以支持Spring无缝集成,不使用Jsp但可以支持Jsp,业界有很多不错模板引擎,如Freemark、Velocity等,他们一直致力于前端与后台分离,关于Ajax与后端交互是一个趋势,但交互得需要规范,否则是无法并行开发的,能否分离就看规范的定义了。关于Spring容器的初始化,吸其长处,避其短处,框架不应该是再造轮子,但可以改进轮子。
光石头

引用来自“爪哇老妖”的评论

看了上面的几点,略有感触,感觉楼主有种大包大揽的趋势,框架问世本应该是开放的,不能使用Spring,但可以支持Spring无缝集成,不使用Jsp但可以支持Jsp,业界有很多不错模板引擎,如Freemark、Velocity等,他们一直致力于前端与后台分离,关于Ajax与后端交互是一个趋势,但交互得需要规范,否则是无法并行开发的,能否分离就看规范的定义了。关于Spring容器的初始化,吸其长处,避其短处,框架不应该是再造轮子,但可以改进轮子。

比较赞成你的观点,改造轮子应该是最优选项
空云万里晴

引用来自“爪哇老妖”的评论

看了上面的几点,略有感触,感觉楼主有种大包大揽的趋势,框架问世本应该是开放的,不能使用Spring,但可以支持Spring无缝集成,不使用Jsp但可以支持Jsp,业界有很多不错模板引擎,如Freemark、Velocity等,他们一直致力于前端与后台分离,关于Ajax与后端交互是一个趋势,但交互得需要规范,否则是无法并行开发的,能否分离就看规范的定义了。关于Spring容器的初始化,吸其长处,避其短处,框架不应该是再造轮子,但可以改进轮子。

+1赞成,改造轮子,而不是再造轮子。
黄勇

引用来自“烈冰”的评论

就相当于你自己再做一个spring和hibernate,作为研究还可以,但实际应用的话意义不大

绝不是再造轮子,一定是改造轮子。从狭义来看是学习研究,从广义来看是创新推广。
黄勇

引用来自“空云万里晴”的评论

不考虑支持AOP吗

AOP 这个特性非常好,需要做一些简化,Spring 先后给了好几套方案了,我个人认为基于注解的方案才是最优雅的,这方面我会放到该框架的特性列表中。非常感谢您的评论!
黄勇

引用来自“爪哇老妖”的评论

看了上面的几点,略有感触,感觉楼主有种大包大揽的趋势,框架问世本应该是开放的,不能使用Spring,但可以支持Spring无缝集成,不使用Jsp但可以支持Jsp,业界有很多不错模板引擎,如Freemark、Velocity等,他们一直致力于前端与后台分离,关于Ajax与后端交互是一个趋势,但交互得需要规范,否则是无法并行开发的,能否分离就看规范的定义了。关于Spring容器的初始化,吸其长处,避其短处,框架不应该是再造轮子,但可以改进轮子。

其实 Spring 和 Hibernate 这样的框架发展到今天,它们已经负担很重了,从实践上讲,我们根本不可能完全用尽这些框架所提供的特性,因为这样也是没有必要的,但是它们却为了满足全世界程序员的需求,给我们提供好了,我们只需要拿来就可以用,确实非常强大,对我们非常友好。但是如果要改进这样的框架,我们必须去阅读成千上万行源代码,而且还不敢去改,因为真的太大了。所以我们需要有自己的框架,既能满足团队的需求,又能方便扩展,我想这个也是我想做这件事情的缘由。非常感谢您专业的评价!
×
黄勇
如果觉得我的文章对您有用,请随意打赏。您的支持将鼓励我继续创作!
* 金额(元)
¥1 ¥5 ¥10 ¥20 其他金额
打赏人
留言
* 支付类型
微信扫码支付
打赏金额:
已支付成功
打赏金额: