For what it is worth, we have a workaround that works for us. I am sure other DataSource users have stumbled across the same solution, but just in case...

• Create a data transfer object ("DTO") that is passed to the page as the model for the view.
• The DTO should declare a read-only string property named Id.
• The value of the Id property should be the primary key for the entity being displayed in the grid.
• If the entity has a multi-column primary key, either:
  • Declare an artificial single-property primary key (e.g., in SQL Server a table with a uniqueidentifier as the primary key) and return the string representation of that property as the value of the Id property,
    OR
  • Implement the Id property to return a string concatenation of the values of the primary key properties delimited with the pipe "|" character.

Since we were already using DTO's anyway, this workaround was a good fit for us. We declared an abstract base class that all of our DTO classes inherit from. The base class declares a public virtual string Id property that only has a getter that returns string.Empty. Descendant DTO classes must override the Id property and return the primary key property value converted to a string (either the single-property PK or the multi-property PK concatenated with pipe "|" characters).

This really needs to be looked at.  We implemented a method to pass two values back to the controller when editing but when you cancel edit, the grid puts the wrong record back.

Surprised and very disappointed that multi-column primary keys are not supported. This severely limits the usefulness of the DataSource, and since the DataSource is at the heart of--well, just about EVERYTHING in KendoUI--we will probably start looking at other UI frameworks when our license comes up for renewal.

I use Kendo with a SQL data warehouse with a normalised star schema design in order to achieve scalable performance and parallel operation. This uses large sets of fields as a primary key so the suggested workaround of creating a psuedo key by concatenating just wouldn't be feasible.

The only workaround for this design is to include a separate ID field for use only with Kendo. This destroys performance and has forced us to avoid using Kendo for CRUD operations whenever possible.

I think it's about time composite keys were supported so this can be a true option for use with enterprise grade applications.

I worked around this with a pseudo key as suggested in this post. https://www.telerik.com/forums/composite-datakey-in-kendo-ui-mvc#JlhcEtSyAEqMWaW6TjnDKQ

I have used the following workaround to solve this. 
Usually I have to use buddy or ViewModel classes in the grid, rather than the raw entity framework (or other) classes from the database itself, because the raw classes usually have circular object graphs (because they have parent child relationship fields). 

In the code to create buddy/viewmodel classes from the raw classes, I populate an extra field that I've added to the buddy classes, IDForKendoTemplate, and I give this a unique value (i.e. 1, 2, 3, sequentially) for each object that is converted.  I can then use that field as the ID for kendoUI grids, and to identify parent grids uniquely in templates.

I ran into this too.  A UI framework shouldn't really force us to have our data stored in a certain way to be effective.