Advice on displaying and allowing editing of data using ASP.NET MVC?

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 intial 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 jQury datagrid plug-in) but it feels like these issues are so intertwined that they need to be dealt with in contect of each other.

Thanks

Answer 1

Data Access - ADO.NET is great if you are used to it. I have had quite a great results using Subsonic ActiveRecord. Once installed, it moves the whole data access busywork out of the way without any substantial learning investment, unlike many of the other ORMs. It is free to use and I definitely recommend it. It has support for LINQ, which can make your data access much easier in areas like paging large datasets, which used to be more involved without LINQ.

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.

Answer 2

I would consider using jqGrid (jQuery grid plugin) and implementing inline editing. Create controller actions that return the data it needs as JsonResult. Use either Linq2SQL or Entity Framework to access your data layer.

Home: http://www.trirand.com/blog/

Demos: http://www.trirand.com/blog/jqgrid/jqgrid.html

Answer 3

The MVC framework does not really favour one method of data access over another. Obviously one of the key advantages of MVC is its improved testability so it makes sense to structure your code in such a way that your controllers can be decoupled from data access logic for unit testing. The easiest way to do this is via the repository pattern, which you can implement with ADO.NET.

To render tabular data you would be better off doing this with a foreach loop in a view rather than using a partial. This can get messy if there is complex logic but this can be cleaned up by the use of HTML helpers. See Rob Conery's excellent article on avoiding tag soup for some pointers on this.

I think the best approach to row editing would be to have each row edit make an AJAX request to an edit action so that you do not need to refresh all the data. As MVC handles the binding of action parameters seamlessly this is very easy to do. You can have a specific action for this that sends a status message back for user feedback. I'd roll your own functionality for this as it is very easy to do.

For refresh all the data you I've found the simplest approach is to use a bool? isPartial parameter on your view, when it is not defined or false you render a complete view, when it is present and true you render a partial instead. Then you can call the same action normally on first request and then send through isPartial = true when making an AJAX request. You can then use jQuery to update the HTML of the table as complete block. This is quicker than returning JSON and parsing this client side.