EF、Linq和Telerik的性能问题

你似乎混淆了一些事情。

第一

• MVC中没有像XXXDataSource这样的控件,你可能会在Webforms中找到;这是一种不同的HTTP工作方式。

• JSON语言 /* JSONP公司 *只是用于通过HTTP在客户端和服务器之间发送数据的数据格式(即从网页到MVC控制器再返回)。他们一无所有 完全 与实体框架或数据库有关,除非它们所代表的数据最终往往会出现在服务器端的数据库中 通过其他方式 例如实体框架

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

  { “NewThingName”:“事物的名称”, “NewThingColor”:“蓝色”, “新交易价格”: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(OD数据) 是一种可以以JSON和XML格式(实际上是一种称为AtomPub的特殊XML格式)工作的协议,用于通过HTTP从服务器查询数据和将数据发送到服务器。它不仅仅是像JSON这样的格式,因为它描述了一整套用于与服务器上的资源交互的命令。

• 剑道UI 数据源 框架对象可以使用JSON/JSONP发送数据请求,也可以与OData服务接口,使用哪种服务的选择实际上取决于您正在与什么类型的服务交互。

• 如果你有 WCF数据服务 并且希望通过HTTP公开其数据,OData非常方便,因为对它的支持已经融入WCF;另一方面,如果您正在使用 MVC模式/WebAPI 那么JSON可能是更好的选择,因为WebAPI中的OData支持还没有完成。 (JSONP只是JSON的一种特殊形式,它允许您从其他域获取数据,而Ajax查询中默认不允许这样做)。

• 就我个人而言,我推荐JSON与MVC一起使用KendoUI;我发现它效果更好,但话说回来,这只是我自己的经验。

• MVC的服务器包装器只是在您的 .cshtml 文件夹;它们不会在客户端做任何在纯JavaScript中做不到的事情。就我个人而言,我喜欢它们,因为它们使小部件的设置更容易管理,尤其是初始数据绑定,但您不需要它们,而且它们在运行时几乎与小部件的功能无关。(请注意,您可以混合和匹配,方法是使用包装器进行渲染,然后使用JavaScript自定义小部件的其他部分)

• 服务器包装器提供的另一件事是MVC模型绑定器,用于网格请求以及基于请求自动查询/更新数据库的扩展;尽管这些 似乎 就像节省时间一样,他们可以 实际PITA 因为不可能轻松地自定义数据库的查询方式,而且它会将您与它们的名称空间紧密耦合。

• 我在一个广泛使用剑道小工具的应用程序上工作,我们根本不使用剑道绑定器;所有数据在发送之前都会在客户端形成自定义格式,一旦到达控制器,我们就可以完全控制流程。(我们使用EF与我们的数据库接口!)

第二

• 您的开发伙伴关于EF存在“性能问题”的声明应该得到确凿事实的支持;对于您的特定数据负载,您或您的同事是否实际测量了EF与数据集的预期性能与实际性能?当然,有时数据集可以在原始速度上“击败”Entity Framework,但纯速度只是流程的一个方面-易用性、强类型、使用Linq到Entity查询的能力如何,将复杂的表层次结构映射到易于使用的对象图中?

• 这个 只有 知道的方法是衡量一个与另一个!

还要记住,你不受限制 完全 在MVC控制器中使用实体框架;它们有很多——Linq2SQL、NHibernate、Dapper等等。

希望能有所帮助。