Rails原则：
在rails社区有相当数量的导向性设计原则。理解这些原则到理解rails需要走很长的一段路。
·Framworks are extractions（框架是实践中提取形成的）
在rails社区有相当数量的导向性设计原则。理解这些原则到理解rails需要走很长的一段路。
·Framworks are extractions（框架是实践中提取形成的）
这个原则是跟Rails起源的故事有关的。Rails起源于Basecamp，这是由37singles开发的一个工程管理系统(
[url]http://www.basecamphq.com[/url]). 在DHH做这个项目的时候，他逐渐的把这个工程中用到的代码提取出来，形成了一个框架结构。可以看到，这个框架是直接由解决实际问题的过程中形成的，而不是抽象构思出来的。而这种哲学思想也正在影响着Rails的核心开发人员，他们从现实世界的实际问题中找到解决方法并且不断发展Rails，而不是通过猜想出来的问题来得到解决问题的框架。这也就是说，不需要设计一个rails框架发展的宏伟蓝图或者是制定一个5年计划来发展和优化这个框架，这个框架特点就是从实际的应用提取营养来不断的发展。
·
Convention over configuration 习惯胜过配置
对于那些使用过其他开发框架的web开发者来说，这无疑是个让人兴奋的好消息。对于有些框架来说，经常需要成百上千行的配置代码（经常是以XML的形式来实现），只有经过那样的配置，应用程序才能使用，URL和方法的映射才能正常工作，模型类的属性和数据库里的字段才能对应..习惯胜过配置这条原则告诉我们，无论何时，只要有可能，直接的配置应该被通俗的、符合习惯的方法所取代。举个例子，在用Rails做web开发时对于数据库映射的处理，假定你现在有2张数据库表，users和projects，而User和Project这两个模型之间应该是一对多的关系。用ruby来创建这两个模型之间关系的代码就像下面给出的这样：
class User < ActiveRecord::Base
has_many :projects
end
class Project < ActiveRecord::Base
belongs_to :user
end
has_many :projects
end
class Project < ActiveRecord::Base
belongs_to :user
end
没错，就是这么把这个问题搞定的！这里注意下，Rails内建了一种机制，就是如果你的模型类使用了User（首字母大写，单数）和Project，它会自动的对应数据库里面users（小写，复数形式）表和projects表。
你可能很想知道Rails是怎么就通过这种方式知道了模型类之间的联系呢？这个问题的答案就关系到了另外一个习惯胜过配置的情况：Rails会假定projects表中有一个字段叫做user_id.当然，如果你需要或者是因为某些癖好，你也可以很轻易的跳过这些Rails默认情况下的假设，但是按照Rails提供的这些习惯来做会给你带来更多的好处。
Opinionated software (有套路的软件)
这个原则跟刚刚那个原则有点联系。在使用rails进行软件设计过程中，对于每一个问题怎么思考、怎么解决或者怎么构建都有一套鼓励你这么做或者避免你那么做的固定套路。软件是对现实世界的模拟，然而，并不是所有的软件都主张或者强烈规定这种模拟现实世界的套路性。事实上，很多软件在他们的风格上和实践性上都做了一个看起来比较中立的选择。但是Rails却背道而驰，这种套路性表现的非常强烈，这样也使得在使用rails时对于web开发的每个过程变得非常清晰。还看上面举过得那个例子，Rails主张一个模型类一般要与数据库中的一张表有一一对应关系，单数首字母大写的类名对应小写的复数形式的数据库表名，而且在表的字段中默认的唯一主键是一个递增的id字段。
Don't repeat yourself （不要重复你自己的编码）
另外一个重要的Rails哲学词汇叫做DRY原则，虽然这个词经常被误解，但是这个想法其实很简单：系统中每项知识只应该在一个地方描述。许多开发者都知道这么做的重要性，掌握DRY需要下功夫来学习，也需要在经验中积累，但是Rails为你铺平了道路。
本文转自 fsjoy1983 51CTO博客，原文链接：http://blog.51cto.com/fsjoy/90373，如需转载请自行联系原作者
