Are there any performance benefits to me not using the gridview in asp.net for simple tables querying from a stored procedure and instead writing the html in server code myself. I'm sure my code would certainly be more concise in output.
I am going to propose an alternate solution. If you don't need any of the features of a GridView, why not use a repeater.
A repeater keeps it simple for implementation, but also allows you to have full control over the generated source. Without the issue of string concatentation preformance.
I've found marginal performance improvements with repeaters over GridViews.
No, there are no performance benefits with using a GridView. In general, the GridView is going to decrease a little bit of performance due to the fact that items are written into the ViewState,and additional HTML is generated. The benefits you DO get from the GridView include command events and arguments that can be easily consumed or created, a DataKey "property bag" that allows you to track critical fields in a large result set, as well as many other things. I will add this caveat that I've used GridViews on even very simple result set returns and have not seen any significant performance problems.
If you are simply doing some output from a table query, and not worrying about doing too much interaction with the data from the results itself, "rolling your own" would provide a great solution.
Well, of course it depends on your implementation. You could almost certainly build something that runs faster than the stock gridview.
The problem is, how would you know? The default system for string concatenation in .Net is by it's nature very slow, so it would be easy to accidentally build something that is much slower than the stock gridview. You could of course test things out, but the development time investment is likely to outweigh an server performance gains.
There's an additional possibility here that exists between using a GridView and using a StringBuilder to generate HTML. I'm talking about using the ASP Table class. I have seen impressive speed benefits on using them over a standard GridView when all I'm doing is spitting out data. As an added bonus, I can add a button (or linkbutton) to my output and wire it up with an event handler and still get the functionality of a GridView in that regard.
You'd use it thus:
Dim tab As New Table
For Each row In DataTable.Rows
Dim tabRow as New TableRow
For Each col In row.Columns
dim tabCol as New TableColumn
tabCol .Text = row(col)
tabRow.Controls.Add(tabCol )
Next
tab.Rows.Add(tabRow)
Next
Page.Controls.Add(tab)
Related
I've read tons of sites on this. There are many "Examples" if you call some code with no explanation of how it was generated (design view vs typed) an example or just want to use simple select and update statements.
I have a Gridview. I am populating it using code from a stored proc. Now I want to edit the data. I have nothing set in the properties of the Gridview through design view (datasource, columns, etc.) My question is, how can I set this to allow editing and use a SP to send it back to the database?
Do I have to now manually create columns with code since I chose to not set properties in the design view?
Is it better to set the properties in design view and go that route? I started that way, but had problems when it came to updating with a SP.
I guess the whole do it in the designer vs do it in code thing has me confused.
I started adding RowEdit, RowCommand, etc. to the html and c#, but still don't see the EDIT/CANCEL on the webpage when I run it.
Learn to use the ObjectDataSource. It gives you maximum freedom of what way of storing the data you use - you delegate the select, update and delete to an external class where you just write your code which uses ado, linq, hibernate, a webservice or just anything.
Coding your views directly against fixed database structure would hurt you sooner or later.
I am creating a huge html table using StringBuilder in the code behind, based on various search criterias selected by the user. The logic is complex as I have to create sub heading, nested tables etc. and it is really hard to maintain or modify. Is there a better way to deal with such kind of problems?
Thanks!!
All ASP and Html controls are encapsulated in classes. You're interested in the Table class (for ASP) and HtmlTable for the more light-weight, html-only class.
If I had to choose, I'd go for the html one, unless you want to add server-side events to the table.
A few years ago I was in the same situation. The problem included dynamic columns, subheadings, cells, everything. A typical table would be around 1000 rows and 50 columns (that's 50,000 cells!). The original implementation used a GridView and performed horribly. I rewrote the view to use a Repeater, a very light-weight looping control, with Literal controls. That reigned in a bit of the madness vs. 100% StringBuilder. I combined that with a bunch of static methods which returned string representations for standard html bits (kind of like ASP.NET MVC's "html helpers"), as well as keeping the object model completely isolated. It was all very fast (I forget, but I think the way the Repeater and Literal controls are rendered is directly to the response stream, so performance was comparable to StringBuilder, perhaps even better).
Even the above will be complex, and is akin to your own approach. But the key to maintaining sanity is to keep the different pieces separate (object model, html generation, and dynamic binding). It's almost like building your own ad-hoc framework. But for serious jobs like this, you need to get nitty-gritty when confined to web browsers.
There's always the built in native ASP.NET Table control
http://www.w3schools.com/aspnet/control_table.asp
GridView, ListView, DataList, Table e&.
I am using gridview control of .net framework 4.0. My list contains 1000 of rows which i am binding to a gridview on each postback. Hence, My page is taking time to load I want to speed up the system. Is there any other control available which can enhance the performance or is there any other way to achieve this?
What all i want is faster performance
You might be able to use faster controls, such as the Repeater, but it depends on what feature you really need. Are you only displaying the data or is it editable?
With such a large amount of data you can look at optimizing what HTML you use for rendering, as you may be able to split the page size by half...
First step should be to do a preformance check to find out what exacly is slow.
Check where in the code things take time, it could be one of many things.
1) If the control uses javascript, perhaps the users are on a old version of their browser with a slow javascript engine.
2) Perhaps the issue is bandwidth?
3) Perhaps its missing SQL index
and on it goes.
Dont guess at what is wrong, find out for sure what is taking the time, and solve then one at the time.
Like Forgotten Semicolon suggested loading via Ajax might be solution, it would give the user a better idea what is going on.
Other then that i would would heavly suggest caching if posible, you can use the built in Cache options to cache the datatable.
In addition to the point about not binding on every postback, I am assuming the datasource is an SQL database. You should probably check to see how fast the query runs. Make sure you have properly indexed your tables.
I've received a project for internal use. My application has to store about 100 rows of meta data of a game and each row has about 15 fields maximum. Fields can be game name, game category, maker, source code path, etc. I will most likely have to join about 5-10 tables for each row of record. Only a few people are using it and will receive very little hits. Speed performance is not a much of an issue. The rows of data I have to present must be sortable and searchable
My current solution is to use ASP.NET's GridView control with ASP.NET's AJAX UpdatePanel to give it that ajax feel. I'm thinking of using LINQ-to-SQL as my data access layer. I'm thinking of building my own custom search engine but if there's an existing control that has this feature already, i would prefer to use that; anyone know of such control exist? Anyways what do you guys think?
Update #1:
I'm looking into creating a DynamicData website. Any have thoughts on that?
Use ext.js!
Look at the Grid Samples, its a very shallow learning curve and provides you with amazing results in little to no time.
http://extjs.com/products/extjs/
Basically, you expose your data via a web service (asmx or WCF, your choice), throw the Ext.Js grid onto your html/aspx page and point it at your webservice. Configure the control for things like sorting/searching/expanding/grouping/paging etc (use the api reference http://extjs.com/deploy/dev/docs/).
ASP.NET Dynamic Data looks really cool, particularly for sites where you've got:
lots of data
not a lot of worries about performance
no / little desire to skin / design the site
no / little desire to extend existing / write new functionality.
So I'd say that's a good match for your project.
Gridview is your best bet. It's so powerful if you know how to use it correctly. It does automatic sorting and if you can code pretty well you can get the data to be filterable(if that's a word). It also makes the Connection to the database for you....so in my opinion, you can't beat the gridview when it comes to reports like that.
I always have this notion that writing SQL queries in the code behind is not good compared to writing it using a SqlDataSource
SqlDataAdapter ad = new SqlDataAdapter("SELECT * FROM Categories", myConnection);
DataSet ds = new DataSet();
ad.Fill(ds, "Categories");
myGridView.DataSource = ds;
myGridView.DataBind();
vs.
<asp:SqlDataSource ID="SqlDataSource1" runat="server"
ConnectionString="<%$ ConnectionStrings:myConnection %>"
SelectCommand="SELECT * FROM Categories" />
I feel using SqlDataSource is secure, easy to maintain.
Is my concern true? Please justify.
I wouldn't write SQL queries in code behind full stop. How about a data access layer?
What happens if you want to change your backing store? You're going to have to re-write all your code-behind.
What happens where you need to use the data in more than one place? You duplicate code.
You need think seriously about how you're architecting your solution before writing SQL queries in your code behind. Think about separation and maintainability long before you question the 'security' of SqlDataSource objects. Seriously.
SQL queries in the code-behind and SQL queries in a SqlDataSource are pretty much equivalent.
they're both about the same security-wise; as for easier to maintain, SqlDataSource may be a bit easier in most cases.
A data-access layer is preferred, but SqlDataSource is sometimes a good-enough expediency. I wouldn't hit you with a rolled-up newspaper for using one if you didn't already have a data-access layer and it was for something simple/a one-off.
Neither of your methods are more or less secure than the other. Since your aspx pages are compiled just as your code behind pages are, you don't run the risk of accidentally exposing your SQL statements or database structure simply by using SqlDataSources. However, security isn't your main problem here -- it's maintainability.
Lots of people complained when Microsoft released SqlDataSources as part of .NET 2.0: we believe it encourages and reinforces bad habits.
For any type of project that's larger than a single intranet page, you should look into its well-behaved big brother, the ObjectDataSource. In using an ODS, you're almost constrained into developing a separate model for your data, away from your view.
In my experience, SQLDataSource is good for a quick one-off page to display data and perhaps edit it. But once you get into any kind of complicated scenario (and I always have), it breaks down pretty quickly. Maintainability is a nightmare using both SQLDataSource and straight SQL in the code behind. I've been burned by SQLDataSource many times.
I would at the very least write a Data Access Layer as a separate assembly that you can call into. This will give you a pluggable way to change it out if you need to. Even better would be a data access solution such as NHibernate or LinqToSql, which handles the plumbing for you and prevents you from having to write the whole thing yourself.
SQL in aspx or aspx.cs are both really novice, bad approaches. Look up n-tier / n-layer design, seperation of concerns and any book on software design.
DataSource controls are great for most things. They support paging in grids and serverside caching and may save trips to the database. However one downfall is that if you are doing anything complicated with db transactions, you wont be able to use a transaction across more than one sqldatasource, at least not easily.
because of pooling, two datasources could have different connections and there is no easy way to assign the transaction object before the commands execute.
I've used SQLDataSources to fill a grid, needing an uncomplicated query. Using a stored procedure instead of putting the query right in the SQLDataSource solves the reusability problem. The examples from Telerik controls make use of data sources extensively, but that may be due to the a need for simplicity and not real-world constraints. Another use I have encountered was on a page placed on every site at a client not particularly concerned with security that enabled the staff to execute sql on the fly. It contained a simple SQL query - opening the page was an easy way to check if the database was accessible.