Without SSH/JSP/Servlet,不走寻常路,Java可以更酷

JE沉寂了很久，终于看到一个有活力的帖子了。
提供2点建议

1.看上去LZ想提供一套web应用的full stack解决方案，但是我还是建议LZ把douyu的各个部分（例如容器及编译器、URL映射、ORM、权限等等）模块化，使之可以很方便的被拆卸、替换。这样更便于用户定制化douyu，或者开发符合自己业务场景的模块去替换douyu的某个部分。精简的内核和易扩展性、可插拔性是一个框架成功的关键。像douyu这种侵入性非常强的框架（可能不应该称之为框架了），这点是非常重要的。

2.可以看的出，习惯优于配置这条原则是douyu的设计准则之一，为此douyu的编译器应当是做了相当的工作。但是我还是建议，允许用户在不使用任何默认习惯、奇技淫巧的情况下，依然能完成同样的工作。例如允许模型和数据库中的表不匹配，可以自定义这个关系；允许用户改变url和类名的匹配规则，不让其自动匹配等等。也就是用户要做的事更多了，但可以绕开douyu的魔法，完成一些特殊情况下的任务。


有句话怎么说的，不在乎目的地，只在乎沿途的风景
尽到自己最大努力做的最好吧
也许会有意外的收获呢

最近太忙，等我有空的时候写一篇讨伐Servlet的文章。

这么说吧：那些企图可以干所有事情，囊括所有需求的框架无一例外会走向臃肿和复杂。做一个web快速开发框架或者说平台的第一要素是：必须敢于大胆舍弃，聚焦在解决一个特定领域，才能取得成功。所以让所谓的括插拔，易扩展，自定义见鬼去吧。

在我眼里，Servlet只是提供了一个访问请求参数和输出响应的接口而已，我也只用这些。无所谓的东西，就算自己做平台，不也要提供吗。

手术刀么

从LZ已经内部集成了权限，还想着以后要集成工作流的想法来看，似乎LZ是想做个万能药式的方案，而不是web快速开发呢

如果在web快速开发上想有所突破，不越过PHP和ROR两座大山很有困难，当然了，我很乐意看到三国鼎立的局面。

什么大肠贴，说话太难听了吧。。。

既然java在所谓快速web开发上难以比肩php，干嘛不就用php呢。让java做他该做的事情不就对了么。每一种技术或框架都由他适应的应用情景，何必强求呢。

这说明你根本不了解Servlet。 如果你想绕开Servlet，你就必须自己实现完整的HTTP Server，实现request/response/session/cookie等一套完整的服务器客户端交互机制，你必须扔掉WAR打包机制，扔掉WEB-INF资源加载方式，必须扔掉Tomcat/Jetty/WebLogic/....所有的Java应用服务器，扔掉我们习以为常的Servlet非线程安全的多线程编程机制，所有的都要扔掉。

所以只要摆脱了Servlet，就摆脱了现在JavaEE的所有桎梏，可以从新来过了，于是一个全新的世界开始了。

LZ的精神和动手能力无庸置疑，非常值得支持！
但是另一方面，纯粹个人感觉，LZ的一些基本常识和理论基础有所欠缺，而且实际项目做得不够多，估计没有写过10万行以上代码。
从而导致将精力用在没有必要的地方；而且也有不少用复杂方式解决简单问题的情况。

例如：
1.完善的 WEB SERVER 功能毫无必要，LZ应该集中在 APP SERVER 上。
  其中就像 NIO，就是没有价值的复杂。
  测试环境固然无所谓，生产环境必用专业的 WEB SERVER前端，Apache、Lighttpd、Nigix、Litespeed 等等。
  在可以预见的未来，JAVA写的WEB SERVER绝不可能赶得上这些 C 写的 WEB SERVER（JAVA的内存管理方式决定了这点）。
  （在这方面，Play!framework也是误入歧途）

2.核心与配套功能不分？
  建议将权限、工作流、检验等配套功能与核心分离。
  这个分离不是对使用 Douyu 的开发者来说的，而是对于开发 Douyu 的开发者来说。
  感觉LZ做Douyu，是历练自我多于其他野心，那么这种架构分离的设计，对 LZ 是非常好的锻炼。
  另一个方面，这也是其他开发者能加入 Douyu开发的重要一步。

3.是否真有必要修改 JVM、JAVAC 来达到目的？
  暂时没有看到哪个功能值得付出这么巨大的代价。
  同时，Play!framework也提供了另一种实现方式。
 
虽然在残酷的现实中，Douyu几乎没有成功的可能，但相信LZ已经通过开发Douyu获得了很多。

不过话说回来，不可能的事情，往往可能是最有价值的事情！

期待你讨伐servlet的文章