I took a break from ASP.NET development for several months but now I'm coming back to it. I still prefer web forms to MVC, but for this discussion that may be irrelevant. I have a Premium Collection license and I'm always interested in what can be done to maximize my efficiency in the use of these tools.
Coming back to this after some time off I'm struck by the labor involved to manifest extremely common functionality. Specifically, I'm talking about binding data to controls, with subsequent sort, filter, and paging abilities where supported by the controls (like RadGrid). I know this applies to all ASP.NET development but I'm wondering what we can use in RadControls to simplify our development - or if there is something else I should be considering to merge with RadControls.
We can create classes to support ObjectDataSource but there is always the question of whether the source object should be a DataSet, DataTable, DataView, etc. A basic List<T> doesn't provide extended functionality. I want my UI controls to allow the user to filter and sort client-side data without going back to the server. When going back to the server, the Select DataMethod should provide server-tier filtering and sorting. Paging from a data set created on the server should be as fast as possible, without rebuilding the data set each time to extract a new page.
The ObjectDataSource itself is limited. Manuel Abadia offers customized ODS components to overcome the limitations. Scott Gu is writing a series of blogs on upcoming "vNext" improvements in databinding and related functionality. Many of us choose not to use the ODS for some projects, preferring to bind strongly typed classes directly to the DataSource property of controls and then manually handling the events for all functionality.
Given all of that, we keep rebuilding the same functionality over and over. Has anyone adopted a set of classes that is specifically designed to handle all of these situations? Is there a book that describes the best practices for each case of client- or server-side processing of data sources for specific kinds of components? Is there something special in .NET 4 that addresses a lot of these concerns? Does Telerik have blogs or other documentation that goes in-depth on the best ways to handle NeedsDataSource and other events? ... And I don't mean the same documentation that we've seen over many years, but something new and fresh that picks up where the old documentation leaves off.
I want to put all of this behind me. I want to make use of the latest knowledge and code advances to code faster and more effectively. I want information or an SDK (FOSS or commercial) that does for databinding what RadControls does for the user interface. I want to spend my time on actual functionality rather than on all of this plumbing.
Thanks for your consideration and responses.
Coming back to this after some time off I'm struck by the labor involved to manifest extremely common functionality. Specifically, I'm talking about binding data to controls, with subsequent sort, filter, and paging abilities where supported by the controls (like RadGrid). I know this applies to all ASP.NET development but I'm wondering what we can use in RadControls to simplify our development - or if there is something else I should be considering to merge with RadControls.
We can create classes to support ObjectDataSource but there is always the question of whether the source object should be a DataSet, DataTable, DataView, etc. A basic List<T> doesn't provide extended functionality. I want my UI controls to allow the user to filter and sort client-side data without going back to the server. When going back to the server, the Select DataMethod should provide server-tier filtering and sorting. Paging from a data set created on the server should be as fast as possible, without rebuilding the data set each time to extract a new page.
The ObjectDataSource itself is limited. Manuel Abadia offers customized ODS components to overcome the limitations. Scott Gu is writing a series of blogs on upcoming "vNext" improvements in databinding and related functionality. Many of us choose not to use the ODS for some projects, preferring to bind strongly typed classes directly to the DataSource property of controls and then manually handling the events for all functionality.
Given all of that, we keep rebuilding the same functionality over and over. Has anyone adopted a set of classes that is specifically designed to handle all of these situations? Is there a book that describes the best practices for each case of client- or server-side processing of data sources for specific kinds of components? Is there something special in .NET 4 that addresses a lot of these concerns? Does Telerik have blogs or other documentation that goes in-depth on the best ways to handle NeedsDataSource and other events? ... And I don't mean the same documentation that we've seen over many years, but something new and fresh that picks up where the old documentation leaves off.
I want to put all of this behind me. I want to make use of the latest knowledge and code advances to code faster and more effectively. I want information or an SDK (FOSS or commercial) that does for databinding what RadControls does for the user interface. I want to spend my time on actual functionality rather than on all of this plumbing.
Thanks for your consideration and responses.
3 Answers, 1 is accepted
0
Hi Tonyg,
You raise voice to everlasting concerns that go beyond platform and UI. Unfortunately, we haven't discovered the "silver bullet" yet. There are just too many binding scenarios, data sources, persistent media and business needs - too many to unify under a single data retrieval and transformation pipeline.
We, at Telerik, also do not have the luxury of working with a unified data-binding model. Rather, we strive to provide the flexibility of supporting as many of these as possible, sometimes, at the cost of re-implementing one and the same behavior for different binding scenarios. This does not mean we do not reuse functionality, or do not gather similar data-binding patterns under common "data engine" implementations. But a union of all is still nowhere on the horizon.
What makes the job even harder is the set of benefits and drawbacks of each of these data-binding models, that renders some of these fitter for a particular purpose than others. Some offer ease of setup for basic needs, others - power of control and customization, still others - variety in data representation. While there is probably something for everyone's particular needs, this great variety makes unification a very hard thing to do.
ORM solutions like OpenAccess try to tackle some of these concerns by providing a unified and shaped view of the data, an abstraction of the persistence layer. They hide the plumbing between the data and the business logic and, to a certain extent, free the developer from some of the aspects of managing data.
I believe we can give the floor to the community to further dwell on this.
Veli
the Telerik team
You raise voice to everlasting concerns that go beyond platform and UI. Unfortunately, we haven't discovered the "silver bullet" yet. There are just too many binding scenarios, data sources, persistent media and business needs - too many to unify under a single data retrieval and transformation pipeline.
We, at Telerik, also do not have the luxury of working with a unified data-binding model. Rather, we strive to provide the flexibility of supporting as many of these as possible, sometimes, at the cost of re-implementing one and the same behavior for different binding scenarios. This does not mean we do not reuse functionality, or do not gather similar data-binding patterns under common "data engine" implementations. But a union of all is still nowhere on the horizon.
What makes the job even harder is the set of benefits and drawbacks of each of these data-binding models, that renders some of these fitter for a particular purpose than others. Some offer ease of setup for basic needs, others - power of control and customization, still others - variety in data representation. While there is probably something for everyone's particular needs, this great variety makes unification a very hard thing to do.
ORM solutions like OpenAccess try to tackle some of these concerns by providing a unified and shaped view of the data, an abstraction of the persistence layer. They hide the plumbing between the data and the business logic and, to a certain extent, free the developer from some of the aspects of managing data.
I believe we can give the floor to the community to further dwell on this.
Veli
the Telerik team
Browse the vast support resources we have to jump start your development with RadControls for ASP.NET AJAX. See how to integrate our AJAX controls seamlessly in SharePoint 2007/2010 visiting our common SharePoint portal
0
TonyG
Top achievements
Rank 1
Rank 1
answered on 15 Sep 2011, 11:38 PM
Veli - sincere thanks for your considered response. Yes, I'd like to hear from others in the field as well.
I will add that working with RadGrid again I'm remembering how valuable NeedDataSource is. I've started to use a RadGrid with no datasource, only processing ItemCommand and NeedDataSource for important data events. When ItemCommand is fired, requests for Page, Filter, Sort, and ExpandingGroup (maybe others) can be ignored. After this event, NeedDataSource is fired. Without going back to the database, a cached version of the client's current data set can simply be returned back to the client by assigning a strongly typed class to RadGrid.DataSource. This setup precludes using the strongly typed data for design-time support, but for me that's a small sacrifice, as my personal priority is to ensure proper support for paging, filtering, and sorting. With this setup, paging, filtering, and sorting are all handled for me in the client - that's the burden left unhandled by the ObjectDataSource and others.
I just wish the round trip to the server could be eliminated on demand, as I just keep returning the same data for most postbacks. Of course if that data needs to be refined I want the opportunity, so I'm not complaining. I'm just looking for more control over both the client and server to maximize efficiency.
The practice described addresses some needs, not all. Overall what I'm saying is that there doesn't seem to be a book, video, or class that covers this very narrow field, though it's an area with which countless thousands of us struggle daily and over many years. If any RadControls experts (Falafel and friends?) are looking for ideas for a new book, I'd think that this is something that could be sold to every RadControls user in existence, if not every ASP.NET developer.
Regards.
I will add that working with RadGrid again I'm remembering how valuable NeedDataSource is. I've started to use a RadGrid with no datasource, only processing ItemCommand and NeedDataSource for important data events. When ItemCommand is fired, requests for Page, Filter, Sort, and ExpandingGroup (maybe others) can be ignored. After this event, NeedDataSource is fired. Without going back to the database, a cached version of the client's current data set can simply be returned back to the client by assigning a strongly typed class to RadGrid.DataSource. This setup precludes using the strongly typed data for design-time support, but for me that's a small sacrifice, as my personal priority is to ensure proper support for paging, filtering, and sorting. With this setup, paging, filtering, and sorting are all handled for me in the client - that's the burden left unhandled by the ObjectDataSource and others.
I just wish the round trip to the server could be eliminated on demand, as I just keep returning the same data for most postbacks. Of course if that data needs to be refined I want the opportunity, so I'm not complaining. I'm just looking for more control over both the client and server to maximize efficiency.
The practice described addresses some needs, not all. Overall what I'm saying is that there doesn't seem to be a book, video, or class that covers this very narrow field, though it's an area with which countless thousands of us struggle daily and over many years. If any RadControls experts (Falafel and friends?) are looking for ideas for a new book, I'd think that this is something that could be sold to every RadControls user in existence, if not every ASP.NET developer.
Regards.
0
TonyG - thanks for your input on NeedDataSource and the rest. An event handler to say "hey, I need some data here" is a good thing to have, keeps you safe from thinking whether data is provided at the right time.
Finally, a book, video, article or generally any synthesized format of knowledge on this topic would be an invaluable resource for any ASP.NET developer, indeed.
Greetings,
Veli
the Telerik team
By the way, I can see Microsoft going in a similar direction with ASP.NET vNext. They go with having a "SelectMethod" - a delegate to provide data when needed. Something the Telerik developers have been benefiting from for ages with NeedDataSource :)
Let me also chip in on another concern you raised - reducing server round trips when you work with the same data. Providing all the data at once and then applying all data transformations on the client can surely be done. RadGrid supports this, to the extent that it binds to whatever data you pass it on the client-side. Additionally, it tracks the page index and size, sort and filter expressions all on the client. Having these data transformation parameters, we can easily create a "javascript data engine" that will apply sorting, filtering and paging all on the client. KendoUI uses this approach for its DataSource widget.
What is more concerning here is performance. Data transformations on the client are not scalable. If you have a page size of 100 and a total data row count of 1,000,000 do you want to serialize and load 1 mil objects in your browser? That would probably totally hog the JS thread and kill your browser.
Finally, a book, video, article or generally any synthesized format of knowledge on this topic would be an invaluable resource for any ASP.NET developer, indeed.
Greetings,
Veli
the Telerik team
Browse the vast support resources we have to jump start your development with RadControls for ASP.NET AJAX. See how to integrate our AJAX controls seamlessly in SharePoint 2007/2010 visiting our common SharePoint portal