jquery - 有关使用 ASP.NET MVC 显示和允许编辑数据的建议吗？

Question

我正在开始我的第一个 ASP.NET MVC 项目，我想获得一些有关显示数据库数据的可能方法和一般最佳实践的意见。

简而言之，我的网页正文将以类似表格的格式显示数据库中的数据，每个表格行显示相似的数据。例如:

Name          Age       Position      Date Joined
Jon Smith     23        Striker       18th Mar 2005
John Doe      38        Defender      3rd Jan 1988

就功能而言，我主要想让用户能够编辑数据，并在编辑后将编辑提交到数据库并刷新 View 。我想刷新 View 的原因是因为数据是按日期排序的，如果用户编辑日期字段，我将需要重新排序。

我的主要问题是哪种架构/工具最适合满足我的高层次要求？

根据我迄今为止所做的研究，我的初步结论是:

1. ADO.NET 用于数据检索。这是我以前用过的东西感觉舒服。我喜欢看起来像 LINQ to SQL 但不想要使学习曲线任意我第一次涉足 MVC 时更加陡峭还没有着陆。

2. 部分 View 创建模板，然后迭代 我已经拉回的数据表 来 self 的数据库模型。

3. jQuery允许用户编辑表中的数据，错误检查编辑数据条目等。

此外，我最初的观点是缓存数据并不是这里的关键要求。用户能够更新的唯一字段是字段，如果他们这样做，我将需要立即将该数据提交到数据库，然后刷新 View (因为数据是按日期排序的)。 对此有什么想法吗？

或者，我见过一些模拟数据网格并提供相关功能的 jQuery 插件。我的第一个想法是，我不需要这些插件附带的所有功能(例如斑马条纹、使用列标题中的排序字形按列排序的能力等)，而且我真的没有看到这有任何好处以及我上面概述的解决方案。 再说一次，有理由重新考虑这个观点吗？

最后，当用户编辑日期时，我需要刷新 View 。为了做到这一点，我一直在阅读有关 Html.RenderAction 的内容，这似乎可能是比使用部分 View 更好的选择，因为我可以将应用程序逻辑合并到操作方法中。 我考虑 Html.RenderAction 是否正确，或者我是否误解了它的用法？

希望这篇文章清晰且不会太长。我确实考虑过为每个主题单独发布帖子(例如 Partial View 与 Html.RenderAction、何时使用 jQuery datagrid 插件)，但感觉这些问题是如此交织在一起，以至于需要在彼此的上下文中进行处理。

谢谢

Answer 1

数据访问 - 如果您习惯的话，ADO.NET 会很棒。我使用 Subsonic ActiveRecord 和 PetaPoco 取得了很好的效果。与许多其他 ORM 不同，一旦安装，它就会将整个数据访问繁忙的工作移开，而无需任何大量的学习投资。它们是免费使用的，我绝对推荐它们。

表格 - 如果您在业务类中检索后组合的几组数据之间存在非常复杂的交互，那么部分 View 可能会很有用。但是，如果您呈现的数据来自一个表，或者甚至接近其最终形式作为查询结果，则没有理由使用它们。相反，使用 foreach 循环迭代数据并以这种方式格式化 HTML。

通过这种方式，类似网格的演示非常简单。

<% foreach (var row in Model.Rows) {%>
    [HTML for one row]
<%}%>

这甚至可以使用 HTML 表格来完成，因为您呈现的是数据表格。

<table>
<% foreach (var row in Model.Rows) {%>
    <tr>
        <td>row.Element1</td>
        <td>row.Element2</td>
        <td>row.Element3</td>
    </tr>
<%}%>
</table>

网格外观 - 就外观而言，例如根据内容对数据进行 strip 化或着色，使这些决策成为您发送的模型数据的一部分，并只需在 View 中使用 CSS 类即可实现那。例如，您可以在 OddEven 字段中返回值“odd”或“even”，这将是您可以在样式表中设置样式的 CSS 类。

<table>
<% foreach (var row in Model.Rows) {%>
    <tr class=<%=row.OddEven%>>
        <td>row.Element1</td>
        <td>row.Element2</td>
        <td>row.Element3</td>
    </tr>
<%}%>
</table>

排序 - 至于使用繁重的 jQuery 或 javascript 来排序和操作数据，我会等到出现一些已知的性能问题，然后再担心一直重新加载数据。但是，如果您每次都重新加载数据，您可能会发现网格中的数据不断刷新的问题，并且您的用户发现他们在编辑时丢失了光标的位置或被中断，或者更改在不完整的编辑结束时触发事件在数据库中。

虽然看起来数据网格是按日期顺序排列的，并且有人更改了日期，但最重要的是立即重新使用数据。我并不声称了解您的情况，但经过多年的这样做，我发现仅仅让用户完成他们的工作(例如，可能通过跳过排序)通常更重要的是重新排列行，这通常意味着他们试图编辑的数据已经跳转到其他地方，他们必须再次找到它。

一个引人注目的界面可能是当数据元素更改时在幕后发送保存，但网格不会重新定位或重新排序。当然，下次刷新页面时，它会被重新使用，但不是在编辑 session 期间。只是一个供考虑的想法。

客户端交互 - 如果您的应用有许多用户和大量编辑，并且每次编辑时都刷新数据，则大型数据集可能会导致大量流量。但是，如果这是一个用户或事件有限的内部应用程序，那么这当然不是一个问题。使用 jQuery 编辑数据效果非常好 - 您可以添加调用以在编辑数据时保存数据，这可以为应用程序提供更传统的 Web 应用程序所缺乏的可用性。