Asp.Net动态数据的未来

谁能告诉我asp.net动态数据的未来是什么？它似乎被搁置在一边，以支持MVC。值得花时间在动态数据应用程序上吗？

在我看来，它会死在藤蔓上。

没有品牌，动态数据应用程序可以在几分钟内创建。它适用于不关心UI层的RAD webform开发人员。这将适用于大约内部网场景。然而，MVC沿袭面向非常不同的场景

Asp.net动态数据实体web应用程序将多个层组合为一个层。我知道对象关系映射（objectrelationalmapping，ORM）被认为是未来的趋势，但当层没有暴露出来时，它可能会导致严重的优化问题，并使测试几乎不可能。ADO.NET实体框架（EF）模型和LINQ to SQL模型都是如此。这些是Asp.net动态数据实体web应用程序可用的唯一现成模型提供程序。如果使用MicrosoftAccess，这些功能将无法正常工作

---

然而，当几乎没有时间来设计一个合适的解决方案时，微软在编写应用程序的肮脏方式方面是很有创意的。动态数据实体web就是这样一种技术，可以为其提供支持。您可能已经准备好大致构建Sql Server数据库，因为您预期以后必须对其进行更改。如果您想快速了解网站，当您有更多时间使用Asp.net动态数据实体web应用程序时，您想稍后删除这些网站？EF可以使用外键来确定关系。

参考我以前的工作，asp.net动态数据帮助我为用户构建一个“快速+简单”的数据编辑网格。我可以自定义网格，配置为向用户显示哪些数据

但实际上，asp.net动态数据的目的并不是要做到这一点

---

在ASP.NET MVC 3.0上，webgrid可以通过列表或EF4.0 edmx的强类型模型生成，它可以与ASP.NET动态数据做类似的事情，所以在我看来，ASP.NET动态数据是没有前途的

我认为MVC和动态数据是非常不同的。第一个是编程模型，第二个是另一个编程模型（webforms）的工具。它们可以共存。除了使用MVC的脚手架特性和一个用于创建视图的健全代码生成工具，还有什么用呢？MS创建一个NHibernate+FluentNHibernate+MVC+autogen DB/schemaexport+auto update/schemaupdate+moq+一堆文档+一个向导来定制这一切会这么难吗？我的问题是alt.net太多了，我不喜欢，因此很难找到具备所有这些技能的人。这种做法违背了进行RAD开发的目的，而这正是这项技术的意义所在。在日志运行中，不再需要Microsoft catch up和alt.net。因此，使用当时可用的微软技术很容易。不过，这只是一个意见问题。