-1

与我的一些开发人员伙伴所说的相比，与 ADO.Net/Datasets 相比，EntityFramework/LINQ 似乎存在性能问题。

通过实体框架从 SQL Server 2012 获取/更新数据时，是否可以使用特定的数据源（如 EntityFrameworkDataSource）？我知道这种类型的 DataSource 可用于 WebForms，但是 MVC 呢？

我知道我在 Telerik 上看到的 3 种数据类型是 JSON、JSONP 和 ODATA。但是，这些似乎只适用于 KendoUI Web 产品，而不适用于 ASP.NET MVC 的服务器包装器。

在哪种情况下我会使用其中一种？

4

1 回答 1

3

你似乎混淆了一些事情。

第一的

  • 在 MVC 中没有像 XXXDataSource 这样的控件，您可能会在 Webforms 中找到；这是使用 HTTP 的不同方式。

  • JSON /* JSONP * 只是用于通过 HTTP 在客户端和服务器之间发送数据的数据格式（即从您的网页到您的 MVC 控制器并再次返回）。它们与实体框架或数据库完全没有任何关系，除了它们所代表的数据通常最终通过其他方式（例如实体框架）最终在服务器端的数据库中结束

  • 因此，例如在使用 KendoUI 时 - 它可以发送 JSON 格式的消息，表示您刚刚添加到客户端的 Datalist 中的新项目，该项目将保存在服务器上。消息通过 HTTP 传输到服务器，如下所示：

    { "NewThingName": "事物的名称", "NewThingColor":"Blue", "NewThingPrice":9.99 }

并由 MVC 的模型绑定器映射到 C# 类，如下所示：

public class NewThingModel
{
   public string NewThingName{get;set;}
   public string NewThingColor{get;set;}
   public decimal NewThingPrice{get;set;}
}

那时，图片中不再有 JSON，直到您可以像这样从控制器发回响应：

public class NewThingAddResponse
{
   public int NewThingID{get;set;}
}

这可以追溯到看起来像这样的剑道小部件，即 JSON：

{"NewThingID":5}

然后，Kendo 小部件可以自行更新。在发送数据和接收响应之间发生的事情对于小部件来说根本不感兴趣。

  • OData是一种协议，它可以在 JSON 和 XML 格式（实际上是一种称为 AtomPub 的特殊 xml 格式）下工作，也可以通过 HTTP 从服务器查询/发送数据。它不仅仅是像 JSON 这样的格式，因为它描述了用于与服务器上的资源交互的一整套命令。

  • KendoUI dataSource框架对象可以使用 JSON/JSONP 发送数据请求，还可以与 OData 服务交互，使用哪个服务的选择实际上取决于您正在与之交互的服务类型。

  • 如果您有WCF 数据服务并希望通过 HTTP 公开其数据，那么 OData 非常方便，因为对它的支持已融入 WCF；另一方面，如果您使用的是MVC/WebAPI，那么 JSON 可能是更好的选择，因为 WebAPI 中的 OData 支持尚未完成。（JSONP 只是 JSON 的一种特殊形式，它允许您从其他域获取数据，默认情况下在 Ajax 查询中是不允许的）。

  • 我个人推荐 JSON 和 MVC 来使用 KendoUI；我发现它只是工作得更好，但这只是我自己的经验。

  • MVC 的服务器包装器只是一种更轻松地在.cshtml文件中配置和呈现 Kendo 小部件的方法；他们不会做任何你在客户端用纯 JavaScript 做不到的事情。我个人喜欢它们，因为它们使小部件的设置更容易管理，尤其是初始数据绑定，但您不需要它们，它们在运行时对小部件的功能几乎没有任何影响。（请注意，您可以混合搭配，使用包装器进行渲染，然后使用 JavaScript 自定义小部件的其他部分）

  • 服务器包装器提供的另一件事是用于网格请求之类的 MVC 模型绑定器，以及用于根据请求自动查询/更新数据库的扩展；尽管这些看起来可以节省时间，但它们可以成为真正的 PITA，因为无法轻松自定义查询数据库的方式，并且它将您与它们的名称空间紧密耦合。

  • 我正在开发一个广泛使用剑道小部件的应用程序，我们根本不使用剑道活页夹；所有数据在发送之前都在客户端形成自定义格式，一旦到达控制器，我们就可以完全控制流程。（我们使用 EF 与我们的数据库交互！）

第二

  • 来自您的开发人员的声明，即 EF 存在“性能问题”，应该有确凿的事实支持；您或您的同事是否针对您的特定数据负载实际测量了 EF 与数据集的预期与实际性能？当然，有时数据集可以在原始速度上“击败”实体框架，但纯粹的速度只是您流程的一个方面 - 易用性、强类型、使用 Linq 到实体查询的能力、将复杂的表层次结构映射成简单的消费对象图？

  • 唯一知道的方法是衡量一个对另一个！

还要记住，您完全不限于在 MVC 控制器中使用实体框架；那里有很多——Linq2SQL、NHibernate、Dapper 等等。

希望有帮助。

于 2013-10-15T00:37:22.907 回答