ahkai

这篇文章谈的是Ruby的一个框架的地位，比较认同文章观点，故转载，哈哈，我是开始越来越重视ui了。

Ruby是非常重视ui的语言，开发从ui开始；

.net 基本是分离 ui 与 框架模型，框架模型设计是从表结构设计开始的，不过完全的分离实际上是很难实现的。

因为Ruby没怎么用，就不评价优劣了。

应该说适用范围不同吧，

.net 多用于产品，表关系较复杂的地方，因为架构好，

Ruby多为敏捷开发，对需求把握好。

-----------------以下转载------------------

原创：Jamis Buck
翻译：sparkman

Scaffolding，scaffolding，scaffolding……在最近一篇文章中，我说了“关于scaffolding我还有很多问题”。为什么会这样呢？我的意思是，scaffolding有什么地方不值得喜欢呢？它就是快速应用开发，原型开发，和即将实现。不是吗?不是吗？不是吗？？

明确地说，关于scaffolding，我的问题是：它着重于应用程序的模型，而不是用户界面。它假设你在了解用户怎样操作之前先了解应用程序有关的东西。它假设用户界面可以成功地符合你的程序。坦率地说，它假设得太多了。

不过，请不要误解我的意思：作为教学指导，scaffolding非常棒。它帮Rails初学者快速地制作一个应用程序框架并运行起来，给初学者一个平台可以快速入门而不被太多细节阻碍。这非常好。可是scaffolding并不是用来制作真正的应用程序的。

你的用户并不在意数据模型。面对这个现实吧，他们真的不在意。他们从来不跟数据模型打交道。他们从来不买你精心制作的模型的帐。他们只跟UI进行互动。因此，当你开始写一个应用程序时，你得先考虑用户关心的是什么，这很重要。好好设计UI，画出草图，模拟出来，做成真的。只要你从一个“真正”的UI开始工作，你就能感受到它对你编写应用程序带来多少益处。

一个屏幕能比几百页说明书更能清楚地告诉你需要哪些模型，以及它们之间的关系。一副图胜千字文。更值得注意的是：你从UI开始设计的模型往往和你没有UI先写的模型不同。

此外，使用scaffolding令测试驱动的开发变得不可能，相比之下，从UI开始工作就容易多了。当使用scaffolding时，你先做什么测试？你想要最终产品具有怎样的性能？当你只知道那些你认为你的应用程序需要的模型时，这个问题不是很容易回答。

而当你从UI开始工作时，你可以看到页面上所有的元素和数据，并立刻看到你需要做哪些测试。“如果用户是个管理员，他浏览页面时应该看到这个链接，而别人不能看到。”看，这就是个测试点。你马上就知道了你（最起码）需要“用户”，而其中一些是“管理员”。

我重申一遍，scaffolding是个很棒的学习工具，就像辅助轮子或者和你一起跳伞的教练。而当你做真正的产品时，就得卸下辅助轮子，自己从飞机上跳下来。总之，先设计UI。

译后记

Rails 2.0把scaffolding从内核拿出去，变成了插件。尽管现在的scaffold更RESTful了：它会创建常用的东西：Controller, Helper, Model, Migration, Unit Test, Functional Test。这样他的劣势似乎没什么了。可随之而来的就是复杂性。它也不如从前那么容易入门了。难怪Rails小组如此对待这个鸡肋。

新的scaffolding的用法已经和从前不同，参见Rails 2.0 and Scaffolding Step by Step

本文着重讲的是优先设计UI，因此新的scaffolding并不影响本文的观点。