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

说实在，我也不喜欢写测试代码，但是，没测试过的东西真不应该拿出来，运行都有报异常

动态语言只有高手在用吧。。。

这种说话的口气过于苛责和小家子气了，“人家”已经做了许多，不喜欢写测试代码也不是什么过错。而且也没看到作者说过这种话.

ZHH,希望你能够从Douyu过程中获得愉快，祝你有更多突破！

但是，结果并不重要，过程才是关键:)

真的很佩服LZ啊
整个思路都非常好,很清晰
我现在有个问题就是担心 服务器的效率如何?

这个可以去搞个硕士课题研究或则论文了。

楼主真是有这么多时间研究。

不过从实用上来看目前还没有太大意义。

从创新上也没有太多东西，大部分的功能很多开源框架都有了，楼主只是把它都整合到一起了，但是性能、扩展性等等都面临问题。毕竟很多框架都不是一年二年发展起来的。

作为研究课题算是精品中的精品了

Douyu大概看了下，首先对LZ表示佩服！

一，HelloWorld 例子看明白了，但是有一点，与Douyu耦合,具有侵入性，能否改成无侵入性的呢？

二，在哦ORM那里，关于分布式，能否做到dev不关心哪个具体库呢？(table1，table2，table3 这么写好累啊)

真空兄弟对JAVA颇有微词啊，Java再不济，还有众多巨头在支撑着呢，抗战个七八年不成问题吧，什么时候有动态语言入三甲再议动态言语基因何等高贵不迟。先不管“斗鱼”最后怎么样，至少楼主的精神确实值得我等中国大陆同行学习的，这里还有众多靠Java吃饭的弟兄在支持楼主。

佩服lz的毅力与劳动。

但个人觉得没什么意义。

指出 lz 对 ActiveRecord 和 ORM 的几点错误认识：

1. 表名对应，ActiveRecord 是可以设置不转换复数的，在 environment.rb 中添加一行即可：

ActiveRecord::Base.pluralize_table_names = false

ActiveRecord 模型和表的对应是遵守最佳实践的良好的默认值，如果不满意，可以修改，你甚至可以定义自己的约定方式。


2. 默认情况下 mysql 表名不分大小写的，就算用大写字母建了表，还是小写。


3. orm 的 has_many, many_to_many 是因为：sql join 查询不依赖于外键约束，而且有些数据库根本不支持外键约束。
java 和 sql 相性不合是因为：java 不支持闭包 ……


ps: beginTransaction ... endTransaction 很容易写错，最简单的解决方式就是:

User.transaction {
  ...
}

edit: 去掉了一些跑题的内容

这个说得没错，比如Apache、IIS都实了http协议的功能，只是实现过程中所用技术不同罢了，
要完成的功能没变，只是实现这些功能所用的技术变了而已，
我并不是说Spring一无是处，引用他的话只是为了说明Without Spring之后我也能用别的技术实现Spring所包含的一样功能，
至于是好是坏，由别人说了算。



这种想法可以理解，就像当初Fortran语言刚出来后受到汇编语言顽固派们的反对那样，
质问Fortran语言的编译器如何保证生成的汇编代码或机器码是正确的？
不仅是Fortran编译器，就目前任何一个语言(C/C++/Java)的编译器来说，
编译器都不能保证生成的代码100%正确，这是不可判定的。

再成熟的编译器都有Bug，比如我就在Sun的Javac编译器中找到了几个Bug。

问题的关健是用户的心理问题，只要用户在心理上接受了，用户就会放心去使用。
比如现在你用Java语言编写代码，然后用Javac编译，再放到JVM上运行，
一旦碰到很费解的问题，你的第一个反应肯定是习惯性的从你的代码中找问题，
实在找不出答案了，再怪罪到Javac编译器或JVM上。

把这样的思路套用到你所说的"生成的类无法有效的测试和调试"的问题上也是一样的，
生成的类就好比Javac编译器生成的字节码，字节码中记录了字节在源文件中的行号，
这样JVM抛出异常时你就知道是哪里错了，实际上你也没有对编译器生成的字节码进行测试和调试，
你认为编译器生成的字节码总是对的，编译器本身也不提供让你测试字节码的功能，
如果你发现问题是出在编译器上，这时你只能向Sun的开发人员报告Bug。

同样的，你首先必须在心理上接受Douyu跟据数据库元数据生成的类是对的，
就像你认为Javac编译器生成的字节码是对的那样，Douyu也像所有的编译器那样不能保证
生成的任何代码是100%正确的，只能尽量做到完美，当你发现确实是Douyu的问题时，
你不想报告Bug，那么也不反对你去修改Douyu来自己解决Bug。




Douyu的权限管理模型是个可选的配置，如果你不需要这个功能，
只要把checkPermission设为false就可以了。

Douyu的权限管理模型也只是个最基本的模型，
仅仅是从Java语言代码层面提取出来的，就好比一个新的Java语法或者类库中的某个API，
你可以用这些基础的东西去构造你的实际应用，并不强求你一定要去用。



我也不想过多比较ActiveRecord和Hibernate哪个强哪个弱，纯个人喜好，
优点都是可以借鉴的，比如我就借鉴了Hibernate的方言机制，
这样可以为特定的数据库做优化，
方言机制也是解决"JDBC规范在某些地方过于宽松，从而导致JDBC驱动存在实现差异"的理想方案。
年龄不是问题(我也27)，但是技术总在进步，新思想总会出现，谁也不知道8年后就没有比你强的人。



每个人都想当天才，只是先天或后天条件限制罢了。
如果你是一个追求技术刺激的人，我想你会尝试不同的挑战，当然了，你得事先把眼前的事做好。
一句话，没有什么不可能。


你把问题想得过于复杂了，不过Javac编译器在分析源代码时很容易解决你所说的类型问题，
Javac编译器内部本身就有一个专门的类型系统，Douyu就是用这个类型系统来分析各种类型的，
包括你说的具体类，抽像类，接口，子类推断这些都是类型系统的基本功能，
简单构造，带参构造，初始值，重用这些也是编译器的最基本功能。

如果你细看"2.6 再论Action"那一节，
Action方法的参数类型要么是基本类型要么是有@Form的类，要么是Douyu内置的接口，
都是有一定涵义的，而且Action方法并不同于普通的类中定义的方法，
只有Action方法才能通过uri掉用，Douyu的编译器并不管你普通的类中的方法是什么，
因为这些方法跟uri无关，控制器并不直接调用这些普通类的普通方法。

Action方法最有用的功能就是你把@Form对应的类作为参数类型，
然后提交表单时就会把表单中的数据自动组装到你的Form类中，
你不需要再用request.getParameter(...)去一个个取出来。
"2.6 再论Action"那一节还介绍了更多Action的用法，
比如上传文件时使用public void upload(UploadedFile[] uploadedFiles, ...)这种Action参数声明
形式就很简单了，UploadedFile是Douyu内置的接口，
当发现UploadedFile接口时就推断你想要上传文件，
然后再解析请求后就把一个实现UploadedFile接口的内部实例传给你，
接着你调用UploadedFile接口的方法就可以直接保存文件了。
这不是很方便吗。

总之，Action方法及方法的参数声明是很特殊的，它是与Http请求有关的，
编译器能够推断Action方法及方法的参数到底是用于什么目的。



我在前言中有讲到，Douyu的权限模型目前不支持数据权限，
这个"数据权限"的概念就是业务有关的，这就是我想引入工作流的原因，
因为工作流涉及到各种业务规则，说简单点，工作流就是规则执行器。
用户可配置无非也就是定制各种业务规则，而业务规则总会牵扯到一些内部数据，
比如表中的记录或者运行时某个变量的取值，这些就是"数据权限"要控制的范围。



Douyu的ORM几乎没有任何硬性约定，
一个表中甚至可以没有id那样的主键，在下一个版本中我就会引入Oracle的Rowid特性，
这样在没有主键的情况下也能删除对象，
唯一对表名和列名有要求的就是表名和列名必须是合法的Java标识符，
否则你只能像"2.9.5 自定义数据库映射"讲的那样做一下少量的工作，
把非法的表名和列名重新用一个合法的Java标识符来表示。

可以这么说，Douyu的ORM特别适合旧的数据库系统，
因为那些系统中所有的表已存在了，一启动Douyu服务器后就能动态地把表映射到模型类，
开发人员直接使用这些模型类就可以了。




模型类是不用修改的，如果还要修改那么Douyu的ORM就不能称为自动化了，就变成一个废品了。

你把较验这么细的问题都提出来了，这很好，
这也是我目前认为Douyu的ORM在较验问题上没有找到完美方案的原因，
特别是在String的长度问题上，你必须要从JDBC驱动中进一步获取字符集编码信息，
还有在字段定义时使用的是字节还是字符(比如Oracle中的char类型，就可以是字节的也可以是字符的)，
JDBC规范通常只要求返回字段的长度(比如用getPrecision来获取)，
但是并不要求JDBC驱动说明返回的字段的长度是用字节还是用字符表示。

不过实际情况中，用户输入的值并不总是超过最大值的，比如你定义了长度100，
取回的值的长度通常就是30、40等等，如果不要求很精确，
可以在最大长度上加上一个数值来作为一个预估值，
或者更绝对的，当长度过大时，让数据库直接抛异常。

当然你也可以事先通过前台的JavaScript来校验。

Douyu的模型类只是对表和表中字段类型、长度和各类约束的抽象，
校验也是基于表中的约束(或规则)的，
业务规则较验并不涉及，当然在后续的版本中也会考虑一些方案，
比如给字段设一个正则表达式语法，
或者在目前的实现中实现com.douyu.sql.PropertyListener接口，
然后就可以通过PropertyListener接口的方法来实现业务规则的较验了。

总之在自动校验这块并不出色，老实讲这块功能是在两个星期前刚加入的，
所以你也看到了，在前面的几小节中，讲较验讲得很简单，连个例子都没给，
这就说明这块功能并不完善。


不过，还是非常感谢你的见意，
这就是我在将近一年之后，决定要在网上发布Douyu的原因，
我花了100多个小时写这篇文章，目的除了分享自己的设计理念之外，
也想听到不同的批评意见，这样才能进步。

谢谢.