看到一个新东西ruby rails，仔细看过介绍，不怎么样

先是无意中看到这篇文章，一纸的肉麻话。http://blog.csdn.net/gigix/archive/2007/02/08/1505697.aspx，IT就是这样，出了一样“新东西”，反正真正试的人不多，先就是靠吹，把形容词全用上，如果你真是全部信以为真还才是技术，不如赶快自杀。不过对于新出的这样那样东西，我习惯性还是要了解一下，所以找到这篇文章http://www.ibm.com/developerworks/cn/linux/l-rubyrails/，和这个帮助文库：http://www.ruby-lang.org/en/documentation/。结论还是通常的，有点意思，但不是必要的东西，如果您是一个新手，你熟练掌握这个工具的时间足够你学会一门语言实现您要做的网站，如果你是一个老手，不用学它也可以更快地做出一个更好的网站。它不是一个必要的东西，适合在什么地方呢？i don't know，我觉得应该这种方式应该是在一个大的企业以某种固定的项目模式进行开发时，把这个作为模式选项，配上培养工作，的确可以令自已公司的项目形成一个规范快捷的流程，structs也是这样的功能。作为独立网站项目的开发，无论对新手还是老手，都没有用的。

每一个用众多形容词吹得天花乱坠的软件工具，（特别是到了中国同胞的口中，屁事不懂的外行也能在《程序员》杂志上堆上一堆自已不懂的术语外加形容词赚点稿酬），都会有它的假定的程序模式(pattern)，如果您能透过这些形容词，看到它的程序模式，那么这个工具就能用起来。举例说，在visual studio中（包括.net）它假定的程序模式是主要的功能构件，程序作者只是因应界面事件调用这些功能控件完成工作，因此，同样是面向对象，在visual中就是面对桌口对象，组成一个个form，形成在这些form中捕捉操作事件，激发微软已经提供的种种控制功能函数完成假定的功能操作。所谓在windows上写程序，就是一个写客户端界面的交互程序，所以它的长处是交互事件密集，而服务逻辑罕有。而在java，它的核心是服务器程序，它的功能是可以对任何对象抽象，所以它的面向对象与c++是不一样的，通常，java的对象会反映为一行数据记录，或者是一个特定的操作，一个事件……等等，常用的操作功能由api函数提供，……显然，作为服务器程序工具，它比visual式的程序提供了更强的功能和更广阔的程序空间，更适合作服务器程序。由此可见，同样是面向对象的语言工具java/c++假定场合是不一样的。

尽管说，程序不要紧，什么程序都能实现所有任务，不错，是这样，但各种程序语言，的确也有它最适合的使用场合，它们是为这种场合任务而设计。那么，ruby rail又是为什么场合模式设计的呢？

仍然是参考这篇文章：http://blog.csdn.net/zwwwxy/archive/2005/09/22/487162.aspx；http://blog.csdn.net/zwwwxy/archive/2005/04/16/350408.aspx，等，还有很多，不一一罗列。这几者面对的是同一个问题：在这种基于数据库的网站应用项目中，大量的小数据表和大量的操控这些数据表的交互界面，构成了一个网站项目最主要的工作内容，——既单调，又乏味，没有创造性，没有技术含量；——虽然说，对于程序新手来说，这种用java调用动态sql访问操作数据库记录是是否入门成其为java程序员的标志。但是，对于以高度重用性为职业标准的真正的开发者，重复做这种低技术含量的代码，简直就是一种折磨。我搞出repository/dao和cusp/Lister列表，以及database等等，实际上都是对这种折磨的逃脱：希望用一个程序对付绝大部分同样形式的简单的程序开发，我是这样，ruby也是这样。

Ruby的核心就是要求使用的程序员按规定生成数据表，并按表定义自动生成了一套针对这个单表的管理界面；——能够称为一个开源项目，一定源及到了多表的管理，这才是这类程序工具的难点，j2EE都今天，对于多表绑定的entity bean解决得都不怎么样。这样，开发者就不必再一个个理解这些表内容的后台管理了，而在前台调用时，可以采用它约定的rails脚本读取相应的数据库的记录内容——，这和我使用标签，以及模板中的类EL语法，设想一模一样。

我没有时间把自已做的东西也包装出一个开源代码项目，但自我感觉，不比structs+hibernate和ruby差那里去。我自已是使用repostor/Processor/dao，通过对ent的定义，任何情况下只需要提交一个ent=什么的值，就会自动按定义完成涉及到的数据对象（表）的管理操作、访问，包括可定制的列表。同样，使用tools.Coder可以自动生成它们的entity代码和用于structs/form的表单java代码。甚至，我连定义这些有都嫌麻烦，所以搞出了database.xml，对于小基表就干脆什么xml文本管理，从而不用一个个基表去做管理操作界面了。我觉得我的方案如果熟练了，甚至更为简单，而且，它是经受了性能负载的考验的。

不过，问题就在于“熟练了”三个字，我之所以不会用ruby，并且能用自已的体系做得更简单，是因为“我熟练了”；而对于一个新手来说，已经成为一个开源项目的Ruby rails，无论在文档还是软件的成熟度上，都会比我的hanva　structure好得多的。