冒着被误导的风险，我相信这对 RAD 和应用程序的快速草图很有用。
感觉有点 Ruby 风格，因为它构建了 CRUD 应用程序所需的几乎所有东西。对我们来说工作更轻松，对吧；大多数人都不聪明。
我在工作场所相当环保，我刚开始作为开发人员从事实际工作（隔间和免费咖啡），所以我的意见可能有点偏绿色，但我喜欢更多的 cmets资深人士。
这是否介于 MVC2（基本脚手架）和 Microsoft Lightswitch（向导驱动开发）之间？值得投资吗？
【问题讨论】：
Ruby != Rails，但 IMO Ruby.contains("the sux") && Rails.contains("the sux")
我个人喜欢将动态数据用于管理页面，这些页面实际上没有人可以看到，但需要以对某些管理员用户可用的方式存在。过去，开发团队需要付出相当多的努力才能一起制作，但使用动态数据，这几乎是一种开箱即用的体验。
我建议您查看Tailspin travel，它是 MVC 2 中的一个应用程序，但使用动态数据，集成在同一个 UI 项目中，用于管理方面。
【讨论】：
起初我持怀疑态度，但现在我使用动态数据的次数几乎与使用“标准”ASP.NET 站点一样多。开箱即用，它非常通用，但可自定义，您可以在其中包含标准 ASP.NET 页面。
起初，当我需要从“标准”应用程序访问数据的“后门”时，我会将其用作单独的管理站点。然而，最近，我的方法是进行更多规划，并决定我希望用户通过动态数据机制访问哪些表，以及我希望更好地控制哪些数据。您可以只搭建您想要的表，这适用于您希望最终用户能够添加/删除的“查找”表。一个例子是我们的电子邮件优惠券计划，客户可以注册通过电子邮件接收优惠券。他们可以选择他们的优惠券类别——热食、饮料、煤气、农产品等。整个优惠券计划的管理员需要能够添加和删除类别，而动态数据对于这类事情来说非常棒。
动态数据负责数据验证（安全性和可用性的巨大优势）、映射我们的关系（节省大量时间）并且只是“做对了”。在业务环境中，安全性和生产力是大多数开发人员处理不好的两个非常现实的问题，而动态数据似乎很好地处理了基础问题。
所以是的，我确实认为这是值得的。它非常强大，是您工具箱中的绝佳工具，但需要熟练使用，这需要时间和练习。它不应该是您工具箱中的唯一工具。
【讨论】：
我对此知之甚少，但听起来我不会考虑。每当我在一个应用程序上工作时，我们都倾向于遵循一些基本的架构准则，例如分层/可重用性等。通常我倾向于像这个一样远离快捷工具/框架。 .NET 世界中有很多可用的“简洁”工具，它们可能在某些小型企业/内部应用程序空间中占有一席之地，但对于设计良好的应用程序来说并不是一个好主意。例如将 SQL 嵌入到数据源控件中，可以直接绑定到 GridView 等。
【讨论】：
我听说动态数据的最佳用途之一是为网站快速建立Django-like admin section。它不一定要“完美”，因为它不是针对用户的，但它确实可以快速轻松地为您提供一些不错的可用性。
【讨论】：