API Changes in Kentico 8

API Changes in Kentico 8

Martin Hejtmanek    —    Apr 16, 2014

 

  Provider API changed to DataQuery

I mentioned this as well as what DataQuery is in my previous article http://devnet.kentico.com/articles/kentico-8-technology-dataquery, however, just to make sure that you are aware of it (if in case you didn’t read it, for example), I will cover that here as well.

We have changed the way how to query data from providers and removed the cumbersome method calls such as:

1	var users = UserInfoProvider.GetUsers(where, orderBy, topN, columns);

We have replaced these with a more elegant solution that returns open lazy-loaded query that can be further modified (more information in the mentioned article). The provider now only has a single parameter-less method that gives you all objects, and lets you set further parameters to it.

To convert the previous code to a new version, use the following pattern:

1 2 3 4 5

var users = UserInfoProvider.GetUsers()     .Where(where)     .OrderBy(orderBy)     .TopN(topN)     .Columns(columns);

 
Note a couple of aspects:

• The return type changed from InfoDataSet<UserInfo> to ObjectQuery<UserInfo>, but they have a very similar interface, so whether you use var or just change the type of your variable, you can still work with the results in the same way (enumerate it, or work with it as a DataSet). I recommend you to use var in this case (and everywhere else where Kentico API returns a more complex type, as it will yield an easier transition in case we have to change anything for something better).
• This way, you still pass hardcoded where / orderBy / columns to the query, so you may want to take one more step and use parameterization through abstraction of particular methods that you can learn in the previously mentioned article, and as you will learn later as well. The DataQuery provides a way in which you can pass to the method a full where condition, and we plan to remove this option. One reason for that is security due to possible SQL injections. The other one is performance due to query caching on SQL server. We just didn’t want to make these things too complicated for you, until we convert all Kentico API to call itself the right way as well.
• You don’t need to call methods for parameters that have default values. , for instance when you pass in null values.

We didn’t want to encourage you to use some incomplete method of transition that we would eventually remove anyway, so we didn’t provide you an easier way to do it on purpose. But let me give you a hint in case you decide to use a lot of these calls, and want to postpone this transition for later.

 

What you can do is provide yourselves with the following extension method:

public static TQuery With<TQuery>(this TQuery query, string where = null, string orderBy = null, int topN = 0, string columns = null)
        where TQuery : IDataQuery<TQuery>
    {
        return query
            .Where(where)
            .OrderBy(orderBy)
            .TopN(topN)
            .Columns(columns);
    }

Then use much simpler transition of the old code in the following way:

var users = UserInfoProvider.GetUsers().With(where, orderBy, topN, columns);

This way you can just simply insert „).With(“ to your existing calls. But as I mentioned, we are eventually (I am hoping for Kentico 9) going to drop the support for full string parameters such as the “where” condition, so take that just as a temporary solution in case you get into trouble when converting too much code.

Note how easy extensible DataQuery is without degrading its functionality. Neat, isn’t it?

Similarly, if some of your processes were strongly bound to the original type of the result, you can get the InfoDataSet out of the query this way:

InfoDataSet<UserInfo> users = UserInfoProvider.GetUsers().TypedResult;

We could not provide an implicit cast operator in this case due to a collision with implicit cast to plain DataSet class, which has a higher priority for us in performance-sensitive operations.