rails总结
-------------------------网上找的
事实上，我觉得楼主你现在面临的问题并不是具体的技术细节，因为常规的功能在过了一遍RailsTutorial之后应该就都学会了，无非就是自己动手的时候想不起来。不过这也简单，多看看范例和API就好。
对于初学者而言，最麻烦的就是不知道该如何下手，这个楼主也提到了。我觉得原因不在于具体的技术，而在于对整个产品开发过程的了解还不够。换言之就是对全局的把握和掌控，我想这个需要长时间和大范围的涉猎积累才能有所进步。大多数的coder都会写具体的功能，但是却不会从宏观的角度规划一个产品的roadmap，在常规的开发团队里，这通常都是项目经理或是产品经理的工作，而工程师只需要看着需求文档一个功能一个功能，一个模块一个模块的实现下去就好了，因此就不会觉得迷茫。
问题就是，对于绝大多数个人开发者，并没有参与全局开发的经验，更不要说全局性的设计一个产品了，所以具体的某个技术好学，但总是缺一条线把这些技术连接起来。所以呢，我的建议是在领略过Rails的概貌之后（比如说过了一遍RailsTutorial），先去了解一下一个完整的web产品的组成，梳理出一个线路图出来，就容易找到方向了。
这个事情并不是想象中那么复杂，我们完全可以参照一些成熟的产品架构来学习。举个例子吧，比如说你要开发一个论坛类的产品，那么你首先要为这个产品定义一下大体的功能。我们不谈那些独创的特色功能，就从复制一个典型的论坛说起，都需要什么呢？（这个要靠你自己想，如果你想不出来，就多去看看别的论坛，分析它们拥有哪些功能，功能之间是如何交互和组织的等等。）
这个时候，你要学会自言自语，对着自己说：“假设当我第一次访问这个论坛的时候，我首先看到的是一个欢迎页面。这个页面是否会有动态的内容暂时我还不确定（比如说从论坛的所有板块里提取出的热点话题等等），所以我先当它是个几乎静态的吧。”
此时，你会面临一个选择：我是要生成什么？scaffold?model?controller?
RailsTutorial里实际上给出了答案，就是在最开始解释MVC模型的时候。
对于一次不需要和数据库交互的用户请求，MVC的处理过程是：用户请求（浏览器：发出请求）->路由（router：将请求映射至控制器的行为，也就是action）->控制器（controller：对应的action处理相应的请求，处理后交给视图渲染）->视图（view：渲染完成交换给控制器）->控制器（controller：将结果返回给浏览器）->输出（浏览器接到发出请求后的相应）
可以看到，这个过程里没有model的参与，这是因为我们假设的目标是一个静态的页面，是不需要和数据库模型交互的。这个过程实际上就是RailsTutorial里前五章的内容。
于是，答案就是生成一个controller就够了。scaffold生成的是一个完整的RESTful资源，包括了model,controller,views,assets,test...显然超出了我们的预定计划（当然它也可以做到我们要做的，只不过有点资源浪费罢了），目前需要的不是一个完整的resource。
此外，你还可以多想一步（可选，即使现在想不到，将来也可以手动添加）：既然上述的流程说的是来自用户的一次请求，那么对于其他的请求呢？
刚才提到了，router负责将用户请求映射至action（在controller中），那么对于静态页面来讲，基本上就是你有多少个页面，就要有多少个action，因为每一个页面都会用一个独立的URL来确定位置，也就是有一个独立的请求。
所以，假设我们的静态页面有：首页、关于、帮助、联系，于是我们就可以开始动手执行：
railsgcontrollerstatic_pageshomeabouthelpcontact
在这条命令里，static_pages就是控制器的名字，意思是“静态页面”（这个不是强制的，我只是模仿railstutorial里的做法，这样LZ你也比较熟悉。实际开发中我喜欢对静态页面控制器命名为portals或者entrance，请随意），也就是“用来控制静态页面部分的控制器”。在这个控制器中，拥有四个actions：home/about/help/contact，分别对应计划中的四个页面（当然可以用别的名字，只不过routes.rb里的配置要和它们一一对应，另外不要用CRUD的名称，因为它们是和RESTful资源对应的——这就是“惯例重于配置”的思想）
接下来，router里面设置好如何将用户请求转至对应的action：
rootto:"static_pages#home"
get'/about',to:"static_pages#about"
match'/help',to:"static_pages#help",via:'get'
match'/contact',to:"static_pages#contact"
这几句用语言表述下来就是：
对于来自网站的根路径（root）的get请求，如：http://myapp.com/，转交给static_pages控制器的home行为（action）来处理
对于来自网站的about路径的get请求，如：http://myapp.com/，转交给static_pages控制器的about行为（action）来处理
以下雷同，第三个match+via:‘get’等同于第二个直接get；第四个只有match，代表对于来自该路径的所有类型的请求（getpostput等等）；这里都是举例，实际情况实际处理。
OK，到了这一步，控制器已经可以通过action将处理的结果交给views渲染了。对于静态页面来讲，action的内部几乎不需要写代码，rails通过action的名字就可以找到对应的views。比如说对于aboutaction，对应的视图就是/app/views/static_pages/about.html.erb
接下来，你在视图里写什么，浏览器就可以通过http://myapp.com/about看到什么。
再往后，搞定静态页面之后，你大概会先碰到注册、登陆、验证三部曲。那么这就需要用到model了，因为你需要在数据库里记录一个注册用户的信息啊，对不对？那么实现的思路其实和上面也没什么不同，无非就是在MVC的工作流程里多了model这个环节，同时controller要负责的逻辑处理也酌情增加，于是整体的复杂度有所提升罢了。
That'sit!总结一下就是：
要全面的了解一个web产品到底是怎么设计和定义的（功能？模块？内容？体验？）
要深入的领悟web的通信机制和mvc框架的工作机制
要学习对于各种解决具体问题的具体手段
多测试。尤其是当你不知道要做什么的时候，测试的意义就在于可以让你先把结果写出来，然后提示你距离达到这个结果你还有多远要走
多看文档、视频。比如说上面讲的routes.rb里get/match的区别和用法，一开始我看railstutorial也是不明就里，于是就去看了官方的guide，这才算是明白了。
Rails很简单，但前提是用他的人要有系统而扎实的基础知识。Rails的简单是因为它及其聪慧且优雅的隐藏了一整套web应用框架背后的种种复杂，如果你要驾驭这种简单，你就要懂得背后的复杂——你可以不用学会写如何处理这些复杂，但你至少要知道这些复杂是什么，它们怎么工作的。
即兴写就，看着有点乱，还请各位海涵，希望对LZ有用。