Note that there are some explanatory texts on larger screens.

plurals
  1. PO
    text
    copied!<p><strong>Data Access</strong> - 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.</p> <p><strong>Tables</strong> - 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. </p> <p>Grid-like presentation is pretty easy this way.</p> <pre><code>&lt;% foreach (var row in Model.Rows) {%&gt; [HTML for one row] &lt;%}%&gt; </code></pre> <p>This could even be done with HTML tables, since you presenting tables of data.</p> <pre><code>&lt;table&gt; &lt;% foreach (var row in Model.Rows) {%&gt; &lt;tr&gt; &lt;td&gt;row.Element1&lt;/td&gt; &lt;td&gt;row.Element2&lt;/td&gt; &lt;td&gt;row.Element3&lt;/td&gt; &lt;/tr&gt; &lt;%}%&gt; &lt;/table&gt; </code></pre> <p><strong>Grid Appearance</strong> - 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.</p> <pre><code>&lt;table&gt; &lt;% foreach (var row in Model.Rows) {%&gt; &lt;tr class=&lt;%=row.OddEven%&gt;&gt; &lt;td&gt;row.Element1&lt;/td&gt; &lt;td&gt;row.Element2&lt;/td&gt; &lt;td&gt;row.Element3&lt;/td&gt; &lt;/tr&gt; &lt;%}%&gt; &lt;/table&gt; </code></pre> <p><strong>Sorting</strong> - 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.</p> <p>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. </p> <p>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.</p> <p><strong>Client Interaction</strong> - 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.</p>
 

Querying!

 
Guidance

SQuiL has stopped working due to an internal error.

If you are curious you may find further information in the browser console, which is accessible through the devtools (F12).

Reload