Should we still use a server side grid or a Javascript grid?
We have a big discussion at work concerning how to handle data in grid.
Some people prefer to use Server Side grid which can be bind easily from the server and be updated with Ajax/or Not. And some people prefer to use only Javascript that call WebService to populate a Javascript/html grid.
From a professional perspective, which 开发者_JAVA技巧one is the best for productivity, testability and maintenability?
We are using WebForm .Net 4.0 and Jquery.
I would definitely say JavaScript controls.
I just think that in these things, Microsoft, Telerik and all the other guys have shown themselves to be far inferior to the open-source community (mostly jQuery-based solutions).
AJAX and asynchronous requests have been around for years, yet only recently did Microsoft come out with MVC to support it properly (and from what I'm hearing- they're still not as good as they should be).
another advantage is a far larger variety of controls for client-side than for server side, so you can find one that suits you exactly. and if you need it to do something that doesn't come out-of-the-box, it's open source- you can just implement it yourself.
I'm using jqgrid, and I'm quite happy with it.
I was in the same scenario as you. In the end, I went with a server-side GridView because it was very easy to bind data to it. On the other hand, refreshing the page every time to update the GridView got annoying, so I ultimately used asynchronous post-backs with AJAX update-panels to keep everything smooth.
Ajax would be the answer anyway because nobody likes old fashion post backs and full page reloads... ASP.NET MVC helps a lot since there is not even the old concept of post back and web form page life cycle.
we do are also in the same situation and are still thinking if we use DevExpress MVCGridView extensions or Telerik one, or a full javascript solution like ExtJs which is cool and fast but does not seem to support cell merging which is an important feature for us.
We've had this argument before.
The great thing about asp grids is that they basically just work out of the box with sorting, paging, etc. And you don't have to deal with javascript, which I personally hate. But they are more of a brute force solution. I mean its horribly inefficient to post back, get data from a DB, rebind, rebuild a page, and send it back just to sort a column.
Even with an UpdatePanel around the grid, there is potentially a lot of data going over the wire and a lot of data access just to sort or page a table.
Javascript is uglier, but much more efficient. For one, sorting (and possibly paging) can be handled completely on the client very quickly, which reduces server load. But then you'll have to write custom functionality for this unless you want to use a third party JS table component.
Another option is the use the ASP grids, but modify the functionality with javascript on the fly. That way your server side code can still take advantage of the simple binding and table generation.
We decided to use the ASP grids as they are. If we run into performance issues down the road, we'll change our approach. But for getting something done quickly with a minimal headache, you can't beat the built in controls
精彩评论