TinyFramework 2.0 火热推出,J2EE 应用开发框架 - 开源中国社区
Float_left Icon_close
TinyFramework 2.0 火热推出,J2EE 应用开发框架
悠悠然然 2015年06月10日

TinyFramework 2.0 火热推出,J2EE 应用开发框架

悠悠然然 悠悠然然 发布于2015年06月10日 收藏 121 评论 71

Tiny 框架历经一年的开发,提交数千个 Commits,终于可以发布 2.0 了。

2.0版本较1.0版本,有太多太多的提升,有许许多多解决了有无的问题,因此,也可以看成是一个有显著提升的版本。

  • Issues情况:Tiny主工程共有621个Issues,里面有需求,和改进,有BUG,目前除了20多个无期的需求之外,已经全部处理完毕。这里面大部分是我们自己提出的,也有相当多的由我们的用户及广大开源爱好者们提出的,在此感谢他们对我们的支持。

  • Commits情况:主工程总共的提交数是1710个,贡献者12,除了synyr人员之外,我们可以看到越来越多的人直接为我们提交PullRequest,感谢所有这些人做出的努力与付出。

  • 质量数据:用Sonar评估下来,我们的圈复杂度是2.4每方法,13.5每类,技术债务相对于代码规模,也是相当小的一个水平,Sonar综合评价在88多接近90%。

  • 工具情况:欲善其事,先利其器,Tiny框架非常注重配套工具的开发。

  • 文档方面的情况:开源开的不仅仅是代码,还有文档。900多页的文档内容,不管是对于哪种级别的人员都可以满足大多数的使用需求。

  • 功能扩展方面

这次扩展的功能太多太多,比如模板语言、DSL数据库开发支持、代码生成、开发文档生成,等等。

更多内容可以到文档网站查看,也可以参与我们的社区进行相关讨论。

获取最新代码请到:https://git.oschina.net/tinyframework/tiny 

值得拥有的企业级j2ee应用开发框架套件,专业团队开放,完整的生态体系,活跃的社区氛围,无限的水平扩展能力,7*24不间断运维能力。

我心目中理想的开源框架

  • 她应该是小的、简单的,满足Simple Is Beautiful

  • 她应该是成长性好的,随着不断的扩展,她可以越来越丰满

  • 她应该是有良好工具支持的,为什么要花时间做工具可以完成的事情呢?

  • 她应该是自组装的,也就是尽可能的脱离配置,而是用一种依赖即可用,取消依赖即消失的全自动处理模式

  • 她应该是模块化的,所有的内容都可以被打入jar包而作为一个整体进行发布,并且能支持热部署的,可以开着车儿换轮胎的

  • 她应该是支持水平部署的,想加服务器就加,想减服务器就减

  • 她应该是有良好知识积累体系的,使得使用Tiny框架的人们越用越强,越用越爽

  • 她应该是便于企业降低开发成本的,便于技术经理控制开发进度的,便于开发人员快速上手的

  • 她应该是避免重复劳动的,所有软件参与者都不应该做重复的事情

  • 她应该是自管理的,最好不要让程序员配置这个配置那个

  • 她应该是让人有种"众里寻他千百度,蓦然回首,那人却在,灯火阑珊处”的开发框架

Tiny框架

  • 虽然整体体量比较大,但是它的每个模块都分得非常小,因此非常容易掌握

  • 它的各种组件都可以方便的进行扩展,通过扩展可以不断的提升系统的处理能力

  • 它的工具已经非常强大,而且它还是变得更加强大。

  • 不管是管理台还是过滤器、Servlet,不管是流程组件还是UI组件,还是UI组件包等等都是可以自组装的

  • 在Tiny的世界中Web工程只是个集合,除了配置文件和Pom依赖,不应该有其它东西

  • 支持水平扩展,同时可以支持7*24小时运行

  • 开始团队由金字塔向哑铃型转变,高低水平者各司其职

  • 绝大多数情况下,要做的只是依赖,而不需进行配置

  • "众里寻他千百度,蓦然回首,那人却在,灯火阑珊处”,这一点是我们永远追求的目标

使用Tiny的理由

  • 架构者十几年平台架构经验,避免了N多已经走过的坑

  • 工程结构细化使得一切都可以非常容易理解及掌握

  • 高内聚、低耦合、高质量的代码

  • 完善的文档,快速入门在130页左右,全部文档接近600页,还在不断增加当中

  • 与第三方平台的良好集成能力,想用什么就用什么,有非常低的侵入性

  • 核心、前台、后台、UI、工具一应俱全

  • 可以提供一站式应用开发支持,大多数的情况下都已足够

  • 专职的团队,可以保持项目持续不断的前进

  • 基于架构者设计的开发框架及Tiny上的产品的销售额累计有5个亿左右的销售额

  • 正在构建的Tiny生态圈,上百个UI组件及流程组件已经足够你日常使用,还会有更多被不断加入

Tiny框架适用对象

  • 在校学生,经常会做毕业论文啥的,如果需要搞点有深度的,到Tiny框架中挖挖,可以有不少猛料

  • SOHO一族,整合SSH/I之类框架来做做应用一般是够的,但是Tiny框架依然可以给你不一样的选择

  • 个体或小型企业,很明确,光是SSH/I已经不足让你的方案看起来高大上,也不足以支持业务数据量比较大的时候的应用场景,也不足以支撑居高不下的软件开发实施成本。

  • 中型企业,个体或小型企业碰到的问题你都会碰到,尤其还要考虑是的多系统集成、体系化规范建设、人员复用、资产复用等等诸多问题,自己创建团队需要解决合适的人、巨大的成本,巨大的风险。

质疑的声音

我相信,肯定也会有诸多质疑的声音,这是非常正常的,不过在质疑之前,请先参考一下如下事实:

  • Tiny构建了远超过Velocity性能和功能的模板引擎

  • Tiny构建了基于JDBC Driver的数据库分区分表引擎

  • Tiny构建了高性能的XmlParser、HtmlParser

  • Tiny构建了网络爬虫

  • Tiny构建了DBF读写程序

  • Tiny构建了高效、强大的中文分词引擎

  • Tiny构建了虚拟文件系统,简单、高效、且不存在内存泄露(Apache VFS中存在)

  • Tiny解决了模块化问题,可以把一切资源放入Jar包,甚至JSP

  • Tiny解决了前端UI组件化问题,所有js,css,img都可以打入jar包,而让程序员避免关心UI组件的依赖关系

  • Tiny解决了每次升级的数据库脚本升级问题,程序员可以告别编写升级脚本的生活

  • Tiny解决了缓冲从业务代码中完全剥离的难题

  • Tiny解决了服务的一次开发到处使用难题,WebService,JSON,XML,etc统统不是问题

  • Tiny解决了流程编排全自动排列问题(此项已申请专利)

  • Tiny解决了业务单元热部署的难题

  • Tiny解决了业务对象自动构建

  • Tiny解决了还有许多的技术难题

本站文章除注明转载外,均为本站原创或编译。欢迎任何形式的转载,但请务必注明出处,尊重他人劳动共创开源社区。
转载请注明:文章转载自 开源中国社区 [http://www.oschina.net]
本文标题:TinyFramework 2.0 火热推出,J2EE 应用开发框架
分享
评论(71)
最新评论
0

引用来自“火-星-人”的评论

造轮子爽吗?感觉有点浪费时间的意思
轮子也是不断进步的,100年前轮子跟现在轮子绝不样,另外“不要造轮子”原来是老外忽悠国人的一句话,国人不信,所以才有中国制造业的发展
0

引用来自“shuaia”的评论

之前看了下,好似有些闭源。不知道是不是我看错了~
开的开的,闭的闭的
0
之前看了下,好似有些闭源。不知道是不是我看错了~
0

引用来自“火-星-人”的评论

造轮子爽吗?感觉有点浪费时间的意思
在某种意义上说,你也是个轮子,你觉得你爸妈造你的时候爽么?感觉有点浪费精力的意思。
0
造轮子爽吗?感觉有点浪费时间的意思
0

引用来自“libinjareo”的评论

文档应该写的再清晰、有条理一点,比如Dorado7和BDF2人家开源文档写的绝对完美。应该借鉴。
谢谢提醒
0
文档应该写的再清晰、有条理一点,比如Dorado7和BDF2人家开源文档写的绝对完美。应该借鉴。
0

引用来自“liujiduo”的评论

感觉很屌哦!有空学习一下。
欢迎交流,互相学习
0
感觉很屌哦!有空学习一下。
0

引用来自“TuWei”的评论

支持
谢谢支持~~
0
支持
0

引用来自“江州大树”的评论

加群好久了,一直都没有时间来研究……

引用来自“悠悠然然”的评论

有时间看看:)
0好的
0

引用来自“jokeit”的评论

三人行 有我
0
三人行 有我
0
赞一个 改天借鉴一下
0

引用来自“唐家V”的评论

悠然大师13
汗~~~~
0
悠然大师13
0

引用来自“魁拔”的评论

梁山开源权限引擎的代码量比tiny多哈,技术债务只有97天哈是tiny的1/3
厉害呀~~
0
梁山开源权限引擎的代码量比tiny多哈,技术债务只有97天哈是tiny的1/3
0

引用来自“张立鑫”的评论

对于比LGPL还恐怖的协议,我只能呵呵而过,过早就考虑收费是不是有点商业目的过于明显(还有哪个专利....专利....利...)?对GPLv3并不抵触,但看用在什么上面,Linux和成熟独立软件支持,但是对于框架上我也只能表示连看的兴趣都没有,代码也无法复用,看了也只是浪费时间和潜在的协议争端。发表回复也是我闲的蛋疼哦。。。真是的。。。

引用来自“悠悠然然”的评论

呵呵,恐怖是在于受众角度的一种感受。
不同的协议之间是各有优缺点的,并不一定是越宽松就越好。

引用来自“张立鑫”的评论

这协议不能商用好么?这是最大的问题(其实不完全准确,商用可以,但是必须提供用户源码)

引用来自“悠悠然然”的评论

为什么协议是GPL的呢?原因是它比较适合我们期望的应用场景。
说得直接一点就是不希望太宽松,随便改一下就可以说是自己的东西。实际上Tiny的标准版商业授权费用是客户看着随便给,给多给少都可以,也就是说看客户的心了。
实际上不管是多么宽松的开源协议,并不代表你的成本一定低。而采用GPL协议,比较适合于搞一个生态环境(当然前提是你的东西不错,如果东西不好,啥协议也没有什么用)。
就事论事哦,我只是抱怨一下。使用MIT的jquery生态圈完整且庞大,apache协议更不用说了,多数java框架所采用。尊重别人的劳动成果不是光靠协议完成的,协议在中国没有任何约束性,且没有相关法律保护,完全靠公司/个人对于劳动成果的尊重程度而定。这些并不是选择GPL协议的客观理由,GPL是商业化严重的协议,已经失去了原来的价值(GUN),使其繁衍产品更少。GUN Linux是一个极其特殊的个例,这些人都是由所谓的黑客组成,曾经的出发点是好的,自由免费,现在早已被商业化,沾染了铜臭味。当你真的使用了这部分免费代码,就会有人站在道德的制高点对你进行攻击,原本的协议约束早已变了味道。
顶部