以简求快 Java快速开发框架LML简介

         直入正题，闲话少叙。

         公司的形态，团队的状态，直接影响着我们对开发框架的选择。正如上一篇以简求快的博文所说，我们这样的小成本开发团队，更主要的是追求快而省。框架要开源，不必付出额外的成本；开发要快速，能够更迅速的跟进客户需求；代码要简单，任何经过简单培训的程序员都几乎能够胜任。

         领导一直再给我们灌输快速开发的概念，在此处我予以沿用，不知道有没有区别于敏捷开发的概念。对于概念，我是一窍不通，希望能有牛人解答我心中的疑惑，在此不胜感激。快，对我们这样的轻型团队很重要，几乎也是最重要的一个因素。我们是不可能照着三年两年去做一个项目，这样我们的成本投入太多，反而有没有把握收回。另外，代码简单也是重要的一个因素，因为我们团队是快速的组合，可能频繁的调动人员，离职的也不在少数，代码简单交接工作就更容易了。

         L ML在这种情况下的夹缝中诞生。我并非高手，所以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()向页面输出一段可执行脚本，你或许不了解他的伟大之处，我们经常用它来提示服务端校验结果，而不用刷新页面，更不必要验证之后而导向另一个页面。

         我必定是框架的作者，让我讲框架的优点，我可以讲上一天一夜。

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

         下集预告：框架搭建和预览。