Imagine you’re starting a new project using ASP.NET MVC. Let’s say it’s a project which frequently requires displaying a list of records, like Google or Stack Overflow or an enterprise database application. Which grid should you use?
The obvious answer is, "I don’t know. I’m just getting started. Does it really matter, right now?" Don’t you wish!
There are many grids available for ASP.NET MVC. If you’re prepared to dedicate your project to a single grid at the outset of your project, and never change it, nor support alternate platforms, like mobile, then you can (almost) be a happy developer. But if you think you might want to support mobile devices, tablets, and desktop browsers with the same application, if you acknowledge the possibility that you might want to change your mind about which grid you will use in the future, or if you care about separation of concerns, then you may have a problem.
Most grids don’t support ASP.NET MVC very well. In particular, they often:
- Push presentation concerns into the controller. In my opinion, the specific grid you choose in the manner in which it is rendered (column headers, search features, paging, etc.) is a presentation concern, and belongs in the view portion of an application with MVC architecture. Controllers should be grid-agnostic, both in the datatypes they use and in the way you structure your actions.
- Don’t support DataAnnotations and other features related to MVC 2’s templates. If I have a view model which is marked up with
[DataType(DataType.Date)], then I should not have to do anything further in order to get a grid to display correctly.
- Require too much code in too many places to get a decent grid on the page.
To be clear, I am not writing a new grid. Instead, I’ve written an interface which supports multiple grids, including jqGrid and even plain HTML tables, without requiring special, grid-specific code strewn throughout your application.
I’m releasing this as open source. Actually, it’s already out, but it’s not quite public yet. I have a few more pieces I need to put in place first, like a demo application.
In the meantime, I’d like to get some feedback on the API. My opinion is that most grids which have an MVC integration at all require the programmer to do far too much work in order to get a decently-formatted grid on the page. I admire the emphasis on API beauty which I see in the Rails community.
So I’ll be "releasing" this a little early. It’s not really ready for production use yet. Although the code is solid, I am still making fairly significant changes to the API. I want this to look right, and I’d appreciate the help of anyone reading this blog.
Or, continue on to the next post in this series, examining the API for views.