您认为 ASP.Net 动态数据值得吗？
冒着听起来误导的风险，我相信这对于 RAD 和应用程序的快速草图基本上是有用的。
从某种意义上说，它有点像 Ruby 风格，它几乎支持了 CRUD 应用程序所需的一切。对我们来说工作更轻松，对吧；大多数人对此一无所知。
我在工作场所相当环保，我刚刚开始从事开发人员的实际工作（隔间和免费咖啡），所以我的观点可能有点环保，但我希望得到更多资深人士的一些评论。
这是介于 MVC2（基本脚手架）和 Microsoft Lightswitch（向导驱动开发）之间吗？值得投资吗？
At the risk of sounding misinformed, I'm under the belief that this is basically useful for RAD and fast sketching of an application.
It feels somewhat Ruby-esque in the sense that it scaffolds pretty much everything you need from a CRUD application. Easier work for us, right; and most people are none the wiser.
I'm fairly green in the workplace, I just start working at an actual job as a developer (cubicles and free coffee) so my opinions might be a bit on the green side, but I'd love some comments from more senior people.
Is this somewhere between MVC2(basic scaffolding) and Microsoft Lightswitch(wizard-driven development)? Is it worth ivesting in?
如果你对这篇内容有疑问，欢迎到本站社区发帖提问 参与讨论，获取更多帮助，或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱，如果其他用户或者作者回复了您的评论，将不能在第一时间通知您！
发布评论
评论（4）
就我个人而言，我喜欢在管理页面中使用动态数据，这些页面实际上没有人能看到，但需要以某种管理员用户可用的方式存在。过去，开发团队需要付出相当多的努力才能共同制作这些内容，但使用动态数据，这几乎是一种开箱即用的体验。
我建议您看一下 Tailspin Travel 这是 MVC 2 中的应用程序但在管理端使用集成在同一 UI 项目中的动态数据。
Personally I like to use Dynamic Data for admin pages, those pages that nobody actually gets to see but need to be there in a usable way for some admin user. In the past those used to take quite some effort on the dev team to craft together but with Dynamic Data it's an almost out of the box experience.
I suggest you take a look at Tailspin travel which is an application in MVC 2 but uses Dynamic Data, integrated in the same UI project, for the admin side.
起初我持怀疑态度，但现在我使用动态数据几乎和使用“标准”ASP.NET 站点一样多。开箱即用，它非常通用，但可以自定义，并且您可以在其中包含标准 ASP.NET 页面。
起初，当我需要从“标准”应用程序获取数据的“后门”时，我会将其用作单独的管理站点。然而，最近我的方法是进行更多规划，并决定我希望用户通过动态数据机制访问哪些表，以及我想要更精细地控制哪些数据。您可以只搭建您想要的表，这对于您希望最终用户能够添加/删除的“查找”表很有用。一个例子是我们的电子邮件优惠券计划，客户可以注册通过电子邮件接收优惠券。他们可以选择优惠券类别 - 热食、饮料、天然气、农产品等。整个优惠券计划的管理员需要能够添加和删除类别，而动态数据对于此类事情来说非常有用。
动态数据负责数据验证（对于安全性和可用性来说是一个巨大的优势），映射我们的关系（节省大量时间）并且只是“做对了”。在业务环境中，安全性和生产力是大多数开发人员处理不好的两个非常现实的问题，而动态数据似乎很好地处理了基础知识。
所以是的，我确实认为这是值得的。它非常强大，是您工具箱中的一款出色工具，但需要熟练地运用它，这需要时间和练习。而且它不应该是您工具箱中的唯一工具。
I was skeptical at first, but now I use Dynamic Data almost as much as I do "standard" ASP.NET sites. Out of the box, it's pretty generic, but it's customizable, and you can include standard ASP.NET pages in it.
At first, I would use it as a separate Admin site when I needed a "back door" into the data from a "standard" app. Lately, however, my approach has been to do some more planning, and decide which of the tables I would like users to access via the Dynamic Data mechanisms, and which data I want more fine control over. You can scaffold only the table you want, and this works good for "lookup" tables where you want an end user to be able to add/delete. An example would be in our email coupon program, where customers can sign up to receive coupons via email. They can choose their coupon categories - hot foods, beverages, gas, produce, etc. The administrator of the overall coupon program needs to be able to add and remove categories, and Dynamic Data is WONDERFUL for this sort of thing.
Dynamic data takes care of the data validation (a huge plus for security AND usability), mapping our relationships (a HUGE time saver) and just "does it right". In the business environment, security and productivity are two very real concerns that are handled poorly by most developers, and Dynamic Data seems to handle the basics well.
So yes, I do think it's worth it. It's very powerful and an excellent tool to have in your toolbox, but one that should be wielded with skill, which takes time and practice. And it should not be the only tool in your toolbox.
我听说过的动态数据的最佳用途之一是快速构建 类似 Django 的网站管理部分。它不必是“完美的”，因为它不是针对用户的，但它确实可以快速轻松地为您提供一些良好的可用性。
One of the best uses I've heard for Dynamic Data was to quickly build up an Django-like admin section for a site. It doesn't have to be "perfect" since it isn't aimed at users, but it does give you some nice usability quickly and easily.
我对此知之甚少，但听起来我不会考虑。每当我开发一个应用程序时，我们都会遵循一些基本的架构准则，例如分层/可重用性等。通常我倾向于摆脱像这样的快捷工具/框架。 .NET 世界中有许多“简洁”的工具，它们可能在某些小型企业/内部应用程序空间中占有一席之地，但对于设计良好的应用程序来说，这并不是一个好主意。例如，将 SQL 嵌入到可以直接绑定到 GridView 的数据源控件中，等等。
I know very little about it but it doesn't sounds like something I would consider. Whenever I work on a an application we tend to follow some basic architectural guidelines such as layering/reusability etc. Typically I tend to get away from shortcut tools/frameworks as this one. There are a lot of "neat" tools that are available in the .NET world that have their place in certain small business/internal app space perhaps, but are not a great idea for a well designed application. For example embedding SQL into the datasource controls that can be bound directly to GridViews, etc.