In recent projects we’ve been making heavy use of the Kentico DataQuery API. This API was introduced in Kentico 8 to replace the provider-based data access methods.
It’s sort of like Linq but not quite the same, though you can mix it with Linq to some degree.
In upcoming posts I’ll dive into some of the gritty details and share some of the lessons learned while applying the Kentico DataQuery API in real life projects, both with the classic Portal engine and MVC.
Why should you use this API?
Mostly because Repeaters will only get you so far. As soon things get more complicated you’ll need to fallback to a data access method that gives you more control.
You can write very complex queries in 10 or 20 lines of code with this APU. It’s very much tuned to Kentico and it’s content.
One of the huge benefits of this is that the queries you build in code are actually testable. Yes, you can write integration tests to exercise your code automatically. And yes that actually works.
What are the drawbacks?
No caching. That’s a big one.
All that lovely caching that you get for free with most of the Kentico Portal Engine controls is now your own concern. You do still get to use Kentico’s caching with the handy cache dependencies that we all love to manage on our data intensive web parts. But now you have to write a bit of code to make that work. More on that in another post.
Posts in this series