The last few years, nearly every web application I’ve built has been using the MVC pattern, and pretty much all of those using the ASP.NET MVC framework. I’ve worked out some repeatable patterns that make building a certain kind of application (straightforward CRUD and similar apps) very straightforward. That’s a good thing given how often the projects in front of me line up with that pattern.
But, there’s another kind of application I’m wanting to build and being asked to build. It’s characterized with a more sophisticated UI that has “richer” interactions. While that could be steered in the direction of Silverlight, most of the time, my clients (and myself for a couple of upcoming applications) really want more devices targeted than Silverlight supports.
I did a bit of digging into the framework, looking through the examples and it all just “clicked” with me. It makes so much sense for client-side heavy web apps. I’ve got some needs on client projects as well as 2 products that I’m 50% owner of underway right now where KnockoutJS is a really good fit, so I’m plowing ahead with it.
That, of course, necessitated a prototype to get myself a little bit oriented to the framework. I figured a good place to start is with an “advanced search” screen. These are screens that are nearly always asked for in apps. But, with all of the moving parts, they’re actually tricky to get right and to include everything people want.
What usually happens (at least what I’ve seen) is that most of the feature makes it in, but there’s always at least some that gets left out from the following list:
- Multi-field search. Search by any of a variety of parameters.
- Sorting by any one of several columns.
- Pagination of resulting data. That includes varying page size.
- Dependent fields. If Field A changes, the options for Field B should change as well.
- Complete layout/content control of the data rows.
Given that that’s usually a screen that’s more tricky to build than your typical CRUD screen, I figured it would be a good prototype for me to determine how difficult KnockoutJS was going to be to work with.
I started with a database I’ve got for generating data for other databases. For instance, if you join a few tables together, you can generate random “fake” users for your site, chosen by gender, give them semi-realistic fake addresses, etc.
Part of that database is a list of cities of the world, the regions and countries they are in. So, I built an advanced search over the cities.
I used ASP.NET MVC as the back end, writing a quick Entity Framework layer over the database. The search controller action itself is pretty hacky/basic code, but it served the purpose of letting me exercise KnockoutJS.
Once I got going, I also got curious about how this might work with OData. Since KnockoutJS in my prototype (and in general) is sending data to and fro in JSON and OData lets you put a URL-addressable layer over your data on the web, I wondered if you could expose an OData service directly to your KnockoutJS client-side app and let it access the data directly.
Enter DataJS, which handles the data out of OData and makes it more digestible as JSON. So, I included a view that did a more basic search directly to the OData service, which was a little different, but still fairly straightforward.
If you’d like to take a look at the code for my prototype, you can download it here.