Monday, January 03, 2011
by
Stefan Dobrev
|
Although Rossen has stated almost all of the things in his introductory blog post about RadDomainDataSource I wanted to create a separate blog entry which answers the most important question that you might be asking: “Why Telerik have developed their own version of a domain data source component?” Here is the answer:
We felt your pain
We have received numerous forum posts and support tickets stating that you want a codeless approach to data-binding that supports most common data operations without the need for any custom code. During the times when RadDomainDataSource was not available you will have to write hundreds of lines of code in order to support server side filtering. Yes sorting and paging were happening on the server automatically, but who needs them without the power of the built-in Excel like filtering of RadGridView. You wanted a seamless integration between your data and our data oriented components like: RadDataFilter, RadDataPager or RadGridView and this is exactly what we have developed. We are also making sure that any future data component that will be developed will lay on the foundation that we have already established and will integrate smoothly as others do.
We wanted to add value
Microsoft’s DomainDataSource lacks some key capabilities and this is a place for someone like Telerik to step up and fill these holes. Here are some of the v1 features that add value to our offering compared to the Microsoft’s one:
- Filter Composition – we support nesting of filter descriptors to unlimited depth allowing you to compose complex filter conditions.
- Fine grained query parameter control – We expose a PreparedParameterValue event which provides a way for you to change each parameter or handle a possible exception before the entity query is sent to the server. This opens the door for handling any custom query scenario that you might have.
- Along with the control we are shipping a set of extension methods which allow you to write native LINQ expression against an entity query object. Those are very handy in data virtualization scenarios like the one in this blog post.
We heard you - the community
One of the most requested feature on RIA services suggestions forum is “MVVM friendly DomainDataSource”. This question was also asked a great number of times on our forums as well. We as you believe that putting a control in your ViewModel is far away from any best practices and this is the reason why RadDomainDataSource was developed with MVVM in mind. What do we mean by that? We are exposing the heart of the control named – QueryableDomainServiceCollectionView as public class that you can start using in your ViewModels right away. You can learn the details here. So our answer to the MVVM purists out there is: We got you covered!
We wanted to invest in the future
Last but not least we wanted to built a foundation for future data source components that we are going to develop. We are pretty sure that what we have developed can be easily extended to support other data access technologies providing filtering, sorting, grouping, paging and aggregation out-of-the-box. This means that you can expect a pleiad of data source controls coming up during the year.
Having all these objectives on the table we have decided to invest our time in developing RadDomainDataSource for Silverlight. I hope you like the end result as much as we do.
Don’t miss other RadDomainDataSource related blog posts: