Question

I am embarking upon my first ASP.NET MVC project and I would like to get some input on possible ways to display database data and general best practice.

In short, the body of my webpage will show data from my database in a table like format, with each table row showing similar data. For example:

Name          Age       Position      Date Joined
Jon Smith     23        Striker       18th Mar 2005
John Doe      38        Defender      3rd Jan 1988

In terms of functionality, primarily I’d like to give the user the ability to edit the data and, after the edit, commit the edit to the database and refresh the view.The reason I want to refresh the view is because the data is date ordered and I will need to re-sort if the user edits a date field.

My main question is what architecture / tools would be best suited to this fulfil my requirements at a high level?

From the research I have done so far my initial conclusions were:

1. ADO.NET for data retrieval. This is something I have used before and
   feel comfortable with. I like the
   look of LINQ to SQL but don’t want
   to make the learning curve any
   steeper for my first outing into MVC
   land just yet.

2. Partial Views to create a template and then iterate through a
   datatable that I have pulled back
   from my database model.

3. jQuery to allow the user to edit data in the table, error check
   edited data entries etc.

Also, my initial view was that caching the data would not be a key requirement here. The only field a user will be able to update is the field and, if they do, I will need to commit that data to the database immediately and then refresh the view (as the data is date sorted). Any thoughts on this?

Alternatively, I have seen some jQuery plug-ins that emulate a datagrid and provide associated functionality. My first thoughts are that I do not need all the functionality that comes with these plug-ins (e.g. Zebra striping, ability to sort by column using sort glyph in column headers etc .) and I don’t really see any benefit to this over and above the solution I have outlined above. Again, is there reason to reconsider this view?

Finally, when a user edits a date, I will need to refresh the view. In order to do this I had been reading about Html.RenderAction and this seemed like it may be a better option than using Partial Views as I can incorporate application logic into the action method. Am I right to consider Html.RenderAction or have I misunderstood its usage?

Hope this post is clear and not too long. I did consider separate posts for each topic (e.g. Partial View vs. Html.RenderAction, when to use jQuery datagrid plug-in) but it feels like these issues are so intertwined that they need to be dealt with in context of each other.

Thanks

Answer 1

Data Access – ADO.NET is great if you are used to it. I have had great results using Subsonic ActiveRecord and PetaPoco. Once installed, it moves the whole data access busywork out of the way without any substantial learning investment, unlike many of the other ORMs. They are free to use and I definitely recommend them.

Tables – Partial views might be useful if you had very complex interaction of several sets of data that you were combining after retrieval in your business classes. However, if you are presenting data that comes from one table, or even is close to it’s final form as a query result, there is no reason to use them for that. Instead, iterate over data with a foreach loop and format the HTML that way.

Grid-like presentation is pretty easy this way.

<% foreach (var row in Model.Rows) {%>
    [HTML for one row]
<%}%>

This could even be done with HTML tables, since you presenting tables of data.

<table>
<% foreach (var row in Model.Rows) {%>
    <tr>
        <td>row.Element1</td>
        <td>row.Element2</td>
        <td>row.Element3</td>
    </tr>
<%}%>
</table>

Grid Appearance – As far as appearance, such as striping or coloring your data based on content, make those decisions part of the model data you send over and simply use CSS classes in your View to achieve that. For example, you could return the value “odd” or “even” in the OddEven field, which would be CSS classes that you could style in your stylesheet.

<table>
<% foreach (var row in Model.Rows) {%>
    <tr class=<%=row.OddEven%>>
        <td>row.Element1</td>
        <td>row.Element2</td>
        <td>row.Element3</td>
    </tr>
<%}%>
</table>

Sorting – As far as getting into heavy jQuery or javascript for sorting and manipulating the data, I would wait until I had some known performance issue before worrying about reloading data all of the time. However, if you reload data every time, you might find issues with the data in the grid constantly being refreshed and your user finding that they lose the position of the cursor or get interrupted while editing or that the changes trigger events on incomplete edits that end up in the database.

Although it seems like if a grid of data is in date order, and someone changes the date, the most important thing is to resort the data immediately. I don’t claim to know your situation, but after years of doing this, I have found that just letting the user get their work done (perhaps by skipping the resorting, for example) is often more important the rearranging rows, which often means the data the were trying to edit has jumped elsewhere and they have to find it again.

A compelling interface could be that save are sent behind the scenes as the data elements are changed, but the grid does not reposition or resort. Of course, next time the page is refreshed, it would be resorted, but not during the editing session. Just an idea for consideration.

Client Interaction – If your app has many users and lots of edits, large datasets can lead to a lot of traffic if you refresh data on every edit. However, if this is an in-house app with limited users or limited activity, that is certainly not a concern. Using jQuery for editing data works pretty well – you can add calls to save data as it is edited and that can give the app the usability that has been lacking in more traditional web apps.