Question

Seems that there are performance issues with EntityFramework/LINQ in comparison to ADO.Net/Datasets in regards to what some of my fellow developers say.

Is there a specific datasource (like EntityFrameworkDataSource) I can use when getting/updating the data from and to SQL Server 2012 via Entity Framework? I know this type of DataSource is available for WebForms, but what about MVC?

I know the 3 datatypes I saw on Telerik are JSON, JSONP, and ODATA. But, these appear to only be available for the KendoUI Web product, not the Server Wrappers for ASP.NET MVC.

Under which circumstance would I use one over the other?

Was it helpful?

Solution

You seem to be confusing some things.

First

  • There aren't controls like XXXDataSource in MVC that you might find in Webforms; it's a different way of working with HTTP.

  • JSON/*JSONP* are just data formats that are used to send data between the client and the server via HTTP (i.e from your web page to your MVC controller and back again). They have nothing at all to do with Entity framework or databases at all except in the sense that the data they represent often eventually ends up in a database on the server side by other means for e.g Entity Framework

  • So for example when working with KendoUI - it can send a message in JSON format that represents a new item you for e.g just added to the Datalist on the client side, which is to be saved on the server. The message travels over HTTP to the server looking like this:

    { "NewThingName": "The name of the thing", "NewThingColor":"Blue", "NewThingPrice":9.99 }

and is mapped by MVC's model binder to a C# class like this:

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

At that point, there is no more JSON in the picture, until you might send back a response from your controller like this:

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

which goes back to the kendo widget looking like this, i.e JSON:

{"NewThingID":5}

Whereby the Kendo widget can then update itself. What happens in between sending the data and receiving the response is not interesting to the widget at all.

  • OData is a protocol which can work in both JSON and XML format (actually a special xml format called AtomPub) for querying/putting data from and to a server via HTTP as well. It's not just a format like JSON because it describes a full set of commands for interacting with resources on the server.

  • The KendoUI dataSource framework object can send requests for data using JSON/JSONP and can also interface with OData services and the choice of which to use really depends on what type of service you are interacting with.

  • If you've got a WCF Data Service and want to expose its data over HTTP, OData is pretty handy because support for it is baked into WCF; on the other hand if you are using MVC/WebAPI then JSON is probably the better choice as OData support in WebAPI isn't complete yet. (JSONP is just a specialised form of JSON that allows you to get data from other domains, which by default is not allowed in Ajax queries).

  • Personally I recommend JSON with MVC for working with KendoUI; I've found it to just work better but then again that's just my own experience.

  • The Server wrappers for MVC are only a way to more easily configure and render the Kendo widgets in your .cshtml files; they don't do anything that you can't do in pure JavaScript on the client side. Personally I like them as they make setup of the widgets a bit easier to manage especially initial data binding but you do not need them and they have virtually no bearing at all on the functionality of the widget at runtime. (note you can mix and match, by using the wrappers to render and then JavaScript to customise other parts of the widget)

  • One other thing the Server wrappers give is MVC model binders for things like the Grid requests as well as extensions for auto-querying/updating a database based on the request; although these seem like a time-saver they can be a real PITA because it's impossible to easily customise the way in which the database is queried and it tightly couples you to their namespaces.

  • I work on an app that makes extensive use of Kendo widgets and we don't use the kendo binders at all; all data is shaped on the client side into a custom format before being sent and it leaves us in total control of the process once it hits the controllers.(we use EF to interface with our database!)

Second

  • Statements from your fellow developers that EF has "performance issues" ought to be backed up by hard facts; have you or your colleagues actually measured the expected vs actual performance of EF vs Datasets for your specific data loads? Certainly there are times when Datasets can "beat" Entity Framework on raw speed, but pure speed is only one aspect of your process - what about ease of use, strong typing, ability to use Linq to Entity queries, map complex table hierarchies into easy to consume object graphs?

  • The only way to know is to measure one against the other!

Also remember that you are not limited at all to using Entity Framework in your MVC controller; there are lots of them out there - Linq2SQL, NHibernate,Dapper to name but a few.

Hope that helps.

Licensed under: CC-BY-SA with attribution
Not affiliated with StackOverflow
scroll top