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

我基本上详细看了，也跟着一步步做了一下。坚持支持楼主！！！值得学习，关注

Douyu自动生成的模型类有点类似JavaBeans，没有什么逻辑的。

比如有这么个表:

create table pet(
  id  int not null auto_increment,
  name varchar(50) not null,
  age int,
  primary key(id)
);

对应的模型类的源代码就类似这样:

public class Pet {
	public Pet() {}

	private int id;
	boolean b_id = false;
	public void id(int id) {
		this.id = id;
		b_id = true;
	}
	public int id() {
		return id;
	}

	private String name;
	boolean b_name = false;
	public void name(String name) {
		this.name = name;
		b_name = true;
	}
	public String name() {
		return name;
	}

	private int age;
	boolean b_age = false;
	public void age(int age) {
		this.age = age;
		b_age = true;
	}
	public int age() {
		return age;
	}
}

上面那些以b_开头的boolean变量是用来跟踪是否调用过setter方法，
这样当你在调用insert或update时，只须把修改的字段值传回数据库中就行了，
不用把所有的数据都传回去，这样浪费带宽，还影响性能
(特别是那些字符串长度上1000的字段值，比如备注之类的)。

当然，后续版本中，可能会采用BIT位图来取代上面这些b_开头的boolean变量，
还会把name、age这些名称压缩(比如用"v1、v2"来表示)，这样可以少占用内存，
因为类中定义的变量名是保存在JVM的常量池中的，会占用内存空间。

明白了。
有点不爽的是我要改模型就要去改数据库表结构。初始数据脚本也要跟着改。对我这种不熟数据库的人比较痛苦。

我不懂django，所以不发表评论。
还是那句话，就像开篇前言中所说：此文并不是用来批判SSH/JSP/Servlet的，
只是向你讲述了不用SSH/JSP/Servlet之后，
对Javac编译器、Tomcat进行一些改进后也能开发出一个将来可以与Rails媲美(或者超越Rails)的东西，
但是这个东西只是刚有个模样，不能一下就要求她样样完美，
高性能，高稳定性是需要时间来完善的。

不管山寨与否，总之我是很用心在做的，
有人说点鼓励的话我也爱听，起码能乐一下下，
批评的话，我也爱听，要是批评的话有建设性那更是求知不得，
泼冷水的话我也会看，看了也不会对我有什么影响，
我还是每天乐呼呼的做我喜欢做的事。




目前主要专注的就是完善ORM，完善Javac编译器跟Http服务器的交互部份，
完善VIEW层，完善文档，加入单元测试。

Sun的Javac编译器一直都不是多线程安全的，所以稳定性主要在编译器跟Http服务器交互这一块，
性能我没经过严格测试，但是Douyu的Http服务器是从Tomcat6大量改造和优化后而来的，
我对Tomcat6的源码也算是有一定研究，Douyu的Http服务器性能不会比Tomcat6还差。

当然了，光是我说的话你不会信，因为我没提供数据。我想你也没有把我的Douyu下下来运行过。


工作流只是长远计划。

为什么你要去改模型类，不用改的啊。

你把表结构改完后，重新启动Douyu就行了啊，启动Douyu后，模型类自动会根据你的新表结构更新的。

当然了，如果你不熟悉数据库，就有点麻烦，

但说明你们公司分工很细啊，开发人员跟DBA分开，不过开发人员懂点基本的SQL还是应该的吧。

我的意思是在设计阶段模型总是在变，比如要加个属性什么的，grails中我在domain class里比如

class Teacher{
    String name
}

加个年龄属性，就是

class Teacher{
    String name
    Integer age
}

而不是去改表。douyu能做到只改一个地方已经很好了，不过对于不习惯数据库操作的人来说不方便而已。

Douyu会开源的，Douyu的编译器是以OpenJDK Javac编译器为基础的，
只是进行了修改和扩充，并没有像对Tomcat6那样进行全盘改造，
不过OpenJDK Javac编译器使用的是GPL2.0协议，
所以Douyu会采用两个协议开源:
与编译器相关的继续使用GPL2.0协议，
其他部份使用Apache License Version 2.0协议。

只是目前内部实现代码不漂亮，没有文档，也不稳定，
如果想到更好的设计思路时，随时都可能重写某些代码，
所以我才说目前不推荐把Douyu用于正式项目开发，
也不推荐去读Douyu的代码，现在没有开源，并不是我想要隐藏什么见不得人的事，
或者是怀有什么意图，别人Sun公司连Javac编译器、JVM都开源了，
我为什么不开源，如果Javac编译器不开源，我哪来发这篇文章的机会。



这个我肯定欢迎，回帖真的需要时间，比如这两天我大部份时间都花在回帖上了，
别人认真回你的帖说明别人想给你点有用的意见，
所以我不能无视别人的好意。


这个一直在努力，比如一些可选模块(像权限)都会考虑通过一个开关参数来控制是否开启。
插件这个要看Douyu下一步怎么做了，如果有些模块能够真正达到自动化了，
就没必要任何干预了，无法自动化的，可以提供接口自由扩展。


Douyu所完成的一些功能的需求背景，
也是基于我以前工作几年中的实际项目经验的，
我现在也在试着用Douyu去重写以前的代码(有的还是PHP的)，
看看到底优势在哪里。

我不了解grails，不过说来有趣，
Douyu的ORM最初就是用grails这种先有模型类，再根据模型类生成表的，
但是后来我把这种方案舍弃了，
原因很简单，编译器能分析开发人员手写的模型类的任何格式，
但是却不能自由控制数据库，因为每个数据库都是不一样的，都有自己的专有特性。
除非你自己再为每个数据库都实现一个你自己的JDBC驱动程序，
否则自动生成的SQL语句对于DBA来说很难让他满意的，
还不如反过来，先有表再有模型类，这也是JDBC的强项，同时还减轻了编译器的负担。

不同数据库的问题我想hibernate处理的还可以。Grails也就是利用了hibernate的功能。
douyu的这种ORM方式目前看起来是贫血模型，是不是用户自己要外面再包一层把逻辑放进去？

呵呵，还好你只是个人感觉，不然我可能真的有点听不下去，
实际项目不多，但是也曾像现在大多数程序员一样在公司写代码做项目，4年时间不算太多也不短，
只是最近这4年不再做应用项目了而已，改行做现在的事了。

基本常识和理论基础要看哪方面的啦，每个人都有很多不懂的。

如果纯粹讲代码量的话，曾用PHP一个人写过一个商业项目就写了15万多行。
如果讲的是代码质量的话，Javac编译器+Tomcat6的源代码光是看就看了30万行，
当然如果你认为读懂30万行代码比你写10万行代码简单的话，那我真的要向你学习了，
我宁愿自己写60万行代码也不愿读懂10万行代码。

不过，我得承认，我并没做过像163，阿里巴巴这种对性能要求很苛刻的大项目。


说实在的，正如我讲过的，我并不想自已写Http服务器，
当你在开发一种新的东西时，这个东西需要涉及Http，但是因为是新的，
目前已有的Http SERVER肯定不会主动给你提供接口的，为了能正常进行测试开发，
当然得自己实现一个先了，不过NIO也并不是没价值，
我就用NIO实现了一个线程调度模型，效果还不错，只是在编程习惯上需要180度转变，
因为是非阻塞的，在同时处理成千上万个请求时，服务线程在处理一个请求处理到一半时，
如果暂时没有数据可读或可写了，必须记住当前的处理状态，然后去服务别的请求，
有数据之后得到通知了再从上一次的中断处继续处理，所以比传统的阻塞IO要难一点。

长远来看，如果要支持集群，我也会把Tomcat6的AprProcessor相关的部份移植到Douyu，
这样就可以跟Apache整合了。


我做Douyu，不是历练也不是野心，只是一个技术痴迷者的正常行为。

核心与配套分了，可能只是文章写得不怎么好，没有明确说明而已，
Douyu的内核就是Douyu的Javac编译器还有一个核心的ResourceLoader，
其他都是配套，可以通过配置参数控制是否开启。

等正式开源后，写好文档了，我欢迎任何有兴趣的人加入。



Douyu没有修改JVM，只是修改了Javac，
是否值得付出是要你看懂了Javac后才会明白它是多么有用的。
Play!framework我今天看了大半天，它也是用了编译器，只不过不是Javac，而是JDT，
还用了无数的第三方jar库，连VIEW层都是使用其他实现的，
Douyu目前很小，加Javac一起才1M多点，Play!framework解压后80多M了，
Douyu的VIEW层也是由Javac编译，只是语法没Play!framework强大。