疯狂java


您现在的位置: 疯狂软件 >> 新闻资讯 >> 正文

Java快速开发框架LML


 

LML在这种情况下的夹缝中诞生。我并非高手,所以LML也不算完善。

首先:LML基于SSH。一直以来都被公司使用的Castle框架的快速简洁而折服,在不追求运行效率的情况下,它堪称完美,这当然还要感谢带它来 公司的某经理。但是,别人的终究是别人的,打心里觉得自己的才是最好的。我水平有限,我没有能力能够在java平台上从头开始造一款媲美Castle的框 架。站在巨人的肩膀上,很多东西就不是很复杂了。SSH是为人熟知的开源Java Web框架,成熟而又稳定,使用率也比较靠谱,于是萌发了在SSH的基础上在此封装改造,形成一套框架的想法。         

其次:LML的模板引擎使用velocity,语法简单,也可以很容易的借用codesmith等代码生成工具生成模板。这实在是符合代码简单的原 则!使用velocity的另外一个原因是我们在。Net中一直使用Nvelocity,他们二者语法非常类似,大部分代码几乎可以做到无修改移植。这一 点以后会有事例的。         

第三:LML支持layout。无论是使用frame还是采用各种嵌入页面的方式,都是为了避免重复的书写公用的页面,就像我们在某处声明了一个公 用的变量,那么就不必要到处书写公用变量所代表的值,另外也给修改带来了方便。它其实相当于我们在asp.Net使用的母版。         

第四:html页面(View)直接支持调用在后台提供的静态或者非静态方法。我觉得这样也许被某些人深恶痛绝,我就曾经被一个不知其名的小同学骂 过,但是这必然是很有用的。在原始的aps.net中,我们不分什么前后台,之后出现了MVC,某些人(大部分是刚入门的吧?)一直在叫嚷视图和逻辑分 离。分离难道是绝对的吗?个人认为,视图确实应该和业务逻辑分离,而绝对不能和功能逻辑分离。业务逻辑此处是指为了实现一定的业务而做出的各种复杂的数据 处理,功能逻辑此处是指为了展现数据而做的逻辑处理。我们查数据,那绝对不是目的,真正的目的是展现数据。就像某人怀才不遇,肚子里有千万数据,而不能展 现,那还有什么用呢。我希望能够使用更简便的方式来展现数据,比方更简单的循环,比方这里的我们可以直接调用后台方法进行简单的数据处理,已达到更完美的 数据展现。       

第五:拒绝大量的配置文件。有一种思想叫做,约定优于配置。我一直觉得SSH中需要我们配置的太多,就算一些微不足道理所当然的也要配,简直不胜其 烦。所以我大胆的做出决定如非必要,我将尽量的避免配置文件,比方我不再将Action托管给Spring。与其让Spring采用request作用域 来管理Action,还不如让Action自生自灭的好,反正就算是托管给Spring,我也没有见到效率更快。最新的SSH支持使用注解的方式来管理配 置,但是我仍觉得这没有那么必要。所以对于一般情况,Struts的Action我使用通用配置,约定一下,什么都变得轻松了。这一切都是对我们来说,不 知道各位的情况是怎么样子的?当然还有一些其他的例如log4j等的配置,我也是能简就简。   

     

第六:局限的使用Model。自从面向对象大行其道,渐渐深入人心,好归好,不好的一面也影响了我们的判断。思维固式导致我们要求我们只根据用户的 ID查出姓名和年龄两列是,我们也必须要查出一个具有四十个属性的Model列表。这,好还是不好?我们更提倡使用原生的sql去查询,快速而有效。当 然,在编辑和保存的时候,结合struts2的自动绑定功能,使用Model更能提高编码效率。在使用效率一词时,我是很谨慎的。这里仅仅只是编码效率或 者开发效率,至于运行效率,一系列的绑定翻译操作,最后再执行sql,总没有直接执行sql更快吧?         

第七:淡化常规分层。我一直不提倡所谓的三层架构,什么多层,甚至几十层。有时候整个业务逻辑你只需要写10行代码,而你又被迫要在每一层写一句代 码。汗,现在解脱了。我至今没有见过千万级别的项目架构都是什么样子的,我们做过的最大的项目不过是200-300万,我们得到的经验是:不走寻常路,开 发简单,维护也速度。到现在也没有遇到一个客户说:我心情不好,把你们现在使用的Ms sql换成mysql吧!所以在不考虑这些一直被一些人吵得火热的灵活性可配置的情况下,我们的框架越发展越简单,越趋向于灵活。就目前我能看到的,大部 分设计都是过渡设计。没有必要为了炫耀你的设计模式学得好,此处就非要做一个工厂!简单的才是最好的。       

第八:权限和菜单。我觉得毫无疑问的是,对于一个正在使用,可以被使用的框架来说,不论它怎么分层,也不论它是轻型还是重型,无论如何它都要有自己 的一套菜单和权限管理策略。我们一直做得某些业务系统,权限就是生命,不可马虎。LML就提供了相应的接口,能够方便的收集生成权限和菜单。在接口的基础 上具体的业务系统就可以进行管理了。         

第九:自动化分页。不可避免的分页,也就催生了不可避免的代码。作为一个架构师或者一个项目经理,你可以要求程序员在每一个模块中都要自行搞定分页 逻辑,大部分情况下显示还是能够被简单集成的。这很不妥。LML采用的分页将不必要重复造轮子,无论是查询条件,还是排序,或者字段展现,以及分页选项, 都能够一笔带过,轻轻松松。要的就是这个效果,有了这个谁还有必要不停地写分页呢。         

第十:AJAX支持。一直以来AJAX都是主流技术。坏消息是大家都知道Struts中是不能直接访问servlet API的。好消息是,LML支持return JSON(“”)。就这样,完美的支持了AJAX。还可以使用return JavaScript()向页面输出一段可执行脚本,你或许不了解他的伟大之处,我们经常用它来提示服务端校验结果,而不用刷新页面,更不必要验证之后而 导向另一个页面。         我必定是框架的作者,让我讲框架的优点,我可以讲上一天一夜。         

但是,这并不是我的目的。其实我真正的目的是:树立以简求快的作风,让一些人明白,对于某些需求,简单的才是最好的。