来自桌面客户端背景，没有真正的数据驱动的网页设计经验，我正在研究ASP.NET UI设计，以确定父/子数据的最佳UI模式。
在学习新的UI平台时，我总是倾向于尝试父/子演示，所以这就是我从这里开始的地方。我想我应该使用ASP.NET 2.0，我正在研究构建UI表单的各种方法，其中包含父记录的主列表，然后在单击父项时在页面的第二个网格中显示相关的子记录。最终，即使是儿童记录也是其他孩子的父母，所以我也需要处理。
想一想：选定开放订单中所选客户/订单项的未结订单/未结订单的客户...就像我在WPF中构建相同内容的屏幕一样：http://www.twitpic.com/26w26
我见过的一些技术只是为父母创建了一个简单的旧的shcool href链接表，有一些方法调用基于所选父级查询子项，而我见过的一些技术使用ASP。 NET 2.0数据控件可以完成所有这些工作。 ASP.NET 2.0数据控件是否作弊？真正的开发人员是否使用这些开箱即用的控件，或者他们输出自己的HTML以便他们可以拥有更多控制权？
此外，似乎ASP.NET MVC现在风靡一时，所以我应该考虑一下。当我看一些关于它的介绍时，似乎需要退一步，因为看起来你必须手动创建大量的HTML来呈现列表和数据网格，而不是能够使用ASP.NET 2.0控件。
我有点迷失在哪里消耗能量。
答案 0 :(得分：1)
我不会评论你所要求的父/子部分，而是评论你最后询问的WebForms vs ASP.NET MVC。
我发现使用WebForms 高度 进行开发很烦人。每当我想要从“规范”中做一些事情时，我就不得不与框架斗争，让它以我想要的方式工作。
ASP.NET MVC极大地减轻了这些负担。然而，它是以牺牲你可以开箱即用的各种酷组件为代价的。所以，是的，有更多的手工编码HTML，但最终这将使你的网页开发更加愉快。
答案 1 :(得分：1)
在我提出这个问题6个月之后回到这个问题，现在我已经获得了一些ASP.Net webforms的经验，我将回答我自己的问题。使用像ListView和GridView这样的实际Asp.net控件实际上并不是那么难，我可以看到在表单上使用它们确实是一种常见的做法，而不是觉得你是作弊。当然MVC强迫你降低html编码水平，但在WebForms应用程序上使用Asp.Net控件很好，实际上并不像我担心的那么难。