问题
使用 Knockout 2.0.1、Upshot.js 和 Entity Framework 4.3 构建应用程序的最佳实践是什么？
技术栈
我们的技术堆栈目前看起来像：
• SQL Server 2008 R2 • ASP.NET MVC3（使用 C#）和 Entity Framework 4.3（使用 Code-First） • jQuery 1.7.2 • jQuery-UI 1.8.2 • Knockout 2.0.1 • Upshot.js beta
背景（许多其他开发人员可能会在这里用他们自己的项目代替我们的项目。）
我们正在开发一个新的 Web 应用程序，其中用户体验非常重要。该应用程序涉及许多密切相关的实体。出于各种原因，非常希望将这些实体中的许多或大部分驻留在相同的一般视觉上下文中（并且很可能在同一个“页面”上）。此外，一些页面元素需要与服务器频繁通信。
虽然我们最初打算将 ASP.NET MVC4 用于我们的表示层，但我们很快决定这可能不是最好的方法。在努力让 MVC 做我们想做的事情之后，我们基本上得出结论，我们最好的方法是将几乎所有 UI 逻辑移动到客户端，然后将 JSON 数据来回传递给服务器。单页应用程序似乎非常适合我们客户的需求。
我们一直在评估 Knockout，但由于映射由我们的 ASP.NET MVC 控制器（使用 JSON 操作方法）公开的实体（在 JavaScript 中）所需的工作量，我们并未完全“出售”它。如果有超过 100 个不同的实体，这种手动映射会非常痛苦！
在看到来自 TechDays 荷兰 (http://channel9.msdn.com/Events/TechDays/Techdays-2012-the-Netherlands/2159) 的 Steve Sanderson 关于“单页应用程序”的精彩演示后，我们认为圣诞节来得太早了。Knockout + Upshot 似乎是完美的解决方案。我们没有花任何合理的时间思考问题，就立即通知客户我们将对我们的 UI 工具集进行一些调整。
当我们开始深入研究伴随任何实际应用程序的更微妙的架构问题时，我们意识到几乎没有例子，关于实现方法和最佳实践的想法甚至更少
我们整理了一些棘手的建筑问题，希望得到答案。我们非常感谢您提供的任何想法或解决方案。
在 upshot 和 .NET 之间进行通信的最佳机制是什么？
根据 Denver Developer 在其题为“深入了解 Upshot.js”的博文 (http://denverdeveloper.wordpress.com/2012/03/07/digging-into-upshot-js/) 中，共有三个数据提供者由Upshot.js。这些都是：
• “默认是DataProvider() 并使用/Submit 方法和您提供的操作来使用jQuery 的$.ajax 方法获取数据。• 下一个是 riaDataProvider() – 与第一个类似，但它使用 /json/SubmitChanges 方法和 /json/{your opertion} 来获取数据 • 最后我们还有 odataDataProvider() – 这个完全不同，因为它确实目前不支持更新数据——它是只读的。”</p>
哪个数据提供者更好——默认数据提供者还是 RIA 数据提供者？推荐哪一个？
应该如何配置控制器来管理传入和传出数据？
我们的理解是 WebAPI 控制器只能有一个“Get”方法。如果我们可能有几百个不同的查询（不包括过滤器变体）将针对服务器执行，这是否意味着我们将需要 200 个不同的控制器类？如果是这样，这是否支持使用结果的 riaDataProvider() 以外的数据提供程序？
如何访问和绑定可供 Upshot 使用的元数据？
Upshot 的一个假定好处是它能够查询通过数据注释公开的元数据。（至少这是我们目前的理解。）如何访问字符串长度、默认值、显示名称、描述信息以及是否需要字段的实体属性的元数据？
哪个客户端验证库应该与 Knockout 和 Upshot 一起使用？
假设，使用标准 jQuery 验证需要在所有表单输入字段上绑定“uniqueName”。似乎不鼓励使用 jQuery 验证。Knockout 插件页面 (https://github.com/SteveSanderson/knockout/wiki/Plugins) 列出了两个验证插件——“Knockout.Validation”和“Knock-Knock Validation”。对于一般用途，推荐使用什么工具或插件使用 Knockout 进行验证？
Upshot 如何处理在层次结构中创建和更新对象？
当结果将数据写回服务器时，它会自动处理同时添加父母和他们的孩子，就像在实体框架中已经可以完成的那样吗？我们假设答案是肯定的，但这不是我们尚未测试过的东西。