I have come across the ASP.NET ready made controls like grid, repeater... etc.
For example while dealing with GRID i remember following facts,
ASP.NET V1.1 has DataGrid with "virtual row count" which is heavily used for custom paging which is need of big sites to perform well.
ASP.NET V2.0 added the GridView with all sort of cool features but also split the DataSource parts as different component. Also "virtual row count" is not supported and for pagination to be done DataSource control is need to be used.
After all these thing i thought that ASP.NET control are not made to be used as is for the development.
Please let me know whether i am right or wrong? Also if you think i am wrong PLEASE provide inputs/links which can help me come out of this thinking of mine.
The mjority of the out-of-the-box asp.net controls are very simple, easy to use and they do that they claim to do, reliably. Many people have had issues with the GridView control, particularly with regard to preformance and size of ViewState. Performance issues have only partly been resolved through the use of AJAX.
I agree with #Neil Moss about the Repeater control. It is very flexible and it outputs what you tell it to. For grids, take a look at the JQuery plugin JQGrid. It has none of the performance issues and a lot of the powerful features of many thrid party custom grids. http://www.trirand.net/demoaspnet.aspx
Also, the ListView control is a very good alternative to the GridView as it provides many of the databinding, selection, paging, sorting, modifying features of the gridview (see here) but gives full control over the output template. Here is a good series of articles on the ListView
Although I am a strong advocate of using ASP.NET MVC, there is a considerable learning curve required to do this and the change in mindset required to work properly in the MVC way should not be underestimated.
I've never had a problem using these controls. I find that they have the same advantages and disadvantages as any set of controls - native or third party. If they do 100% of what you need them to do, then fantastic. If they don't give you 100%, and don't give you events or virtual methods to override, then you're stuck and you'd need to go back to more fundamental controls and do a little programming of your own. I always found the repeaters and lists to be very handy in that respect.
to be very short & direct, ASP.NET ready made controls are the best solution for most projects.
I’ll explain you in detail, but first, ASP.NET ready made controls are known as ASP.NET Controls Framework or ASP.NET Controls Library. I am insisting on the key phrases because, when you search google like search engines, you need to search by appropriate keywords to get better results.
There are many control libraries available on the internet and most are offering free tools too. Besides the question whether should I use it in my enterprise applications or not, you need to understand your requirement.
The first point is YES, you can absolutely use the controls in your enterprise applications, because there controls are more reliable and built by control development experts, tested by strong product testing team and are enriched with quality documentation. Note, you will also get good community support, human resources with controls knowledge, and compliance with industry standards. The best of all, you will be able to save your time on all the above factors. Some controls even gain you more advantages with its features & functionalities which you wouldn’t have even thought about.
The most important things you need to do when choosing a control
1. You need to go through their knowledgebase
2. Search relevant articles for the control you choose
3. Download evaluation version and DIY
Many good control libraries are available in the internet. I am using obout control libraries and I recommend you to go for obout. Besides quality control sets, these guys provide personal development support. Most time I can’t separate them from my internal team. Check www.obout.com for yourself.
Related
Hypothetical scenario:
I want to create a web app that will rely heavily on the display of tabular data. The GUI should allow for resizing or columns, grouping by columns using drag and drop and on the fly filtering.
If I went with Web Forms, I know I could buy Telerik and other 3rd party controls to give me this functionality with relative ease. If I went with Razor, I think I would be up the creek trying to strengthen my underdeveloped client side coding skills and would end up with an inferior interface in the end.
I've read about some of the advantages of Razor and its cleanness is compelling, but are there no grid components that would give me rich features like those described above with low development cost, i.e., do I have to write them myself?
I read many of the postings here about Razor and didn't quite see this question addressed, I hope its not really a duplicate.
in fact Telerik, DevXpress, Infragistics, they all have grids for MVC with native filtering, grouping, sorting and I guess also column resize out of the box:
check here the DevXpress MVC extensions's GridView
Don't underestimate the learning curve of ASP.NET MVC 3. It's not as easy as the tutorials would have you believe, and it's very easy to get yourself into a mess with Razor, if you're not careful.
If you're comfortable with WebForms and know you can solve the task with relative ease using that technology, I would recommend staying with it for now.
There are lots of compelling reasons to use MVC, but you don't seem to mention any of them, other than "that's what the cool kids are doing". And that shouldn't be the primary reason. :)
Personally I've been working for years with Telerik's RadControls and DevExpress
ASP.NET controls. IMHO they both produce quite an impressive HTML overhead on the client side thus for that I've never been highly pleased with them.
Of course I also know about Infragistics, ComponentOne, ComponentArt, etc.
I'd assume they are not much different than those I mentioned.
Which (commercial) controls suite generates the most compact HTML on the client side?
I'm inclined to think there is no "most performant controls suite" rather a combination
of server controls and Javascript based controls (eg. jQuery UI). Would you agree with that?
What combinations did you achieve the best/most performant user experience with?
Update 27 Jan 2012
Since my original answer, I have spent a lot of time working with MVC. As I said below, you have full control over the markup generated, which is great. I have also spend some time using Telerik MVC (http://demos.telerik.com/aspnet-mvc) controls and I must say, they have done a great job of keeping the tools functional, while minimising the markup and script sizes. They have introduced a Script registrar which allows you to register which scripts to include on the page. This allows you to also register your own custom scripts, which can be combined into a single resource and compressed for low latency and bandwidth.
Original Accepted Post:
You are correct in that commercial control suites tend to generate heavy markup and script overhead. This is partly due to the fact that they have traditionally had to deal with the ASP.NET postback and viewstate page workflow, which results in long-winded control Ids and a proliferation of many small javascript downloads (adding latency for each file).
Also, many controls tend to try to add too much functionality. They try to do it all but this makes doing anything simple with them quite a chore as there is a steep learning curve for a lot of these suites, as I am sure you are finding.
If you want to improve the download size and markup generated on your page, my advice would be to use a combination of ASP.NET MVC (great control over markup, no viewstate or _doPostBack scripts everywhere) and JQuery plugins, whic you touched on in your question.
Take a look at the markup of StacOverflow. It is written in MVC. Not sure what 3rd partycontrols they use.
The worst offender for hevy markup is often Grids. Take a look at the JQGrid http://trirand.com/blog/jqgrid/jqgrid.html
Try Obout control suit. They are very effective and bring productivity with much low overheads.
http://www.obout.com/
Here we work with ComponentArt and we are really excited about it. It's really easy to implement, looks great and has a lot of functionality in it. Performance is also very good. We also use componentone controls but they aren't very good for web apps I think.
I would definately suggest to use ComponentArt
AlbumOnNet WebControl Suite
AlbumOnNet WebControl Suite is a set of ASP.NET WebControls enabling a Web designer or programmer to use RAD techniques to create great looking Image based Slide shows, Photo Albums, and Image based Ad Rotators.
The controls can be used for product image presentations, real estate photos, art gallery pictures and screenshots.
The controls are programmed to work at its best on the design surface (in the Form Designer) in Visual Studio. Drag and drop a control, like the SlideShow control, on the page, set a few properties and experiment with the Style attributes to match your page design.
WebControls included
Album WebControl
SlideShow WebControl
SlideShow InfoViewer (EXIF codes)
Slide Info Labels
Navigation Buttons
Navigation ToolBars
Numeric link navigation
I have read several other posts here, so i get the idea on the pro vs. cons, especially having full control over the rendered html code etc. (in MVC).
My question is regarding the UI controls: In MVC, i will have to write all UI controls myself (or the html equivalent). Now is that not going to be very difficult?
The reason why these 3rd party vendors for asp.net are there is just because of the fact that it is difficult to write UI controls for ASP.NET all by ourselves, and be able to target to all web browsers, and also that we are better off concentrating our time on the business logic rather than spending the whole lot of time writing the UI controls HTML code ourselves.
I understand that this feature gets us the full control over the final html, but is it not counter-productive to do this UI bit ourselves. If it was so easy to write them ourselves, how come these 3-rd party vendors are all living now. We could have done this all by ourselves all these years of WebForms days.
I am sure i am missing something here or being a little stupid, but please enlighten me as to what i am missing in specific regard to the UI bit being written by ourselves.
Just because i get full control over the program by writing in IL code, do we go and do that? We still use C# and things like that - So that theory of "having full control over html" - i am not bought into that idea.
Please help in getting my head around this UI bit.
Other things i understand, about the separation of concern, TDD based development possible with MVC etc.
But why would i go around writing the UI controls all by myself - it is a bit a work isn't it?
The thing is:
If you want to master in web development you have to master HTML + CSS + Javascript
And with WebForms you have to learn the WebForms way to do it, but with MVC you have the power of .Net with the freedom to generate the HTML + CSS + Javascript you want.
Here's a new rant on the subject http://www.charliedigital.com/PermaLink,guid,6dcb0333-9d70-40c7-975b-0ff4011c4661.aspx
Problem is, ASP.NET MVC is much younger product than ASP.NET. For many years 3rd party companies have been developing TONS of reusable components, and I believe that it is only a matter of time before comparable set of controls will be available for ASP.NET MVC.
If you really need very rich GUI with 3rd party controls, and you can't rewrite them in acceptable time - stick with asp.net. Altough in my opinion, MVC gives you tons of power it wouldn't be wise to spend much more time rewriting controls than you can save. If you can live without controls, and like MVC concepts - use MVC, and you'll most certainly see 3rd party solutions as soon as they'll there is growing market (maybe thay've already noticed that, I don't know) for mvc extensions.
I believe that the UI and the user experience are vital to the success of a web app. Making the page intuitive and easy to use, minimizing the amount of navigation the user has to do to get the job done, and providing effective feedback and interactivity can make all the difference between a site that users want to use and one that they avoid.
If you are trying to attract users on a public website, a pleasing appearance and excellent usability are key to building repeat visits.
If you are writing an intranet app to be used by hundreds or thousands of employees all day long -- as I mostly do -- making the UI efficient and easy to use really means a lot to your users.
So, I wouldn't downplay the importance of the UI. It isn't a nuisance. It's a key part of the user experience. I suggest that a web developer should embrace whatever tools and strategies that will get the job done. That often means coding the UI controls yourself. Or working with a teammate who likes doing that part of the work.
I recently refactored a very complex website using ASP.NET + handworked javascript to MVC + jQuery. The complexity of the code was reduced by 50%-75% and became much more testable. I replaced all the complex webcontrols I had to write (with a steep learning curve I had to overcome) with very simple HtmlHelper methods.
Don't forget, when you use custom webcontrols, you are given a very static UI by the control developer. With raw HTML, you can take advantage of styles and ui developed by the whole web industry.
Increased simplicity, decreased development time, testability, flexibility in UI... I don't want to go back.
You also have to remember that ASP.NET MVC is just the first release. I don't think there is intrinsically any reason why you couldn't have the equivalent of server controls to enable certain tasks - remember, there are many server controls that don't generate any mark-up (such as the Repeater, PlaceHolder, ListView). These type of controls could be useful in a future MVC setting, I think.
I believe that ASP.net came around when lots of developers were still used to doing desktop applications and just beginning web development. AT that point in time abstracting the details of the web with controls and post backs was a great way to get people started. At that point we weren't trying to perfect the web, we just wanted to get on it!
Now that the web has matured and we've all slowly learned about html, css, javascript and the likes we want to optimize our websites for our own needs and we don't want to depend on ASP.net Forms controls to control the fine details of our websites.
In summary, I think this is about the natural evolution of many developers from the desktop to the web
I for one, am very thankful that you cannot use ASP.NET controls in MVC.
Controls, as many have already pointed out, are just server side blocks of code that render HTML and javascript on your behalf. Things like a datagrid are great, until someone asks you to make a slight modification, like having a delete confirmation alert, and then it seems impossible to do certain tasks.
The good news is that there are very powerful jQuery tools written to help you. jQgrid is a great grid replacement that does WAY more than the ASP.NET grid...
http://www.trirand.com/blog/
jsTree is a treeview that is fantastic. Again with the jQuery....
http://www.jstree.com/
And the truth is that most things you can do with razor, HTML, javascript and CSS. It's so simple that it's just stupid.
It's hard for people like myself who were web forms developers to grasp MVC and why you should use it because it's so simple. It's difficult to let go of the complexity of conventional ASP.NET. But it feels so good when you do.
And don't mix web forms with MVC. You can do it, but you will wish you hadn't.
Here is the key thing that I think you are missing. When ASP.NET is no longer the MS way of doing things...you will eventually be forced to move on and do something else. I have programmed in perl, ASP classic, then ColdFusion, then PHP, then ASP.NET web forms, then ASP.NET MVC...the only thing that they all have in common is the underlying database, design patterns, best practices for a given set of technology AND...HTML, JavaScript, CSS, and Photoshop.
No one is asking you to learn MVC. No one is telling you to not use WebForms. However, complaining that you have to write a raw UI is not going to get you very far in this industry. You should be learning something new every day...and it sounds like some time spent on HTML and CSS would be a great place to start your focus!
The biggest problem you have with relying on third party controls is when a client asks you to do something that the third party controls don't cover. If you can't replicate their complexity plus the added feature request on your own you are skirting a possible failure in your professional livelihood! You will need to know how to do it all...eventually!
I generally suggest that you embrace new technologies. You don't have to use them...but you should at least know how. This way you will know what the best tool is for any given project.
I've been wondering - what's an equivalent of 'control' from webforms in asp.net mvc? It's not a partial view for sure. What else it can be? Controller + partial views via partial requests?
Maybe i'm dumb, blind or both, but i haven't seen any 'control' for asp.net mvc. Just a lot of code snippets to accomplish one specific thing or another.
I believe that asp.net mvc is quite unfriendly with rapid development. Only way out of this problem - a lot of open source code (like MvcContrib), tutorials, sample applications & most important - slightly smarter developers.
You do not have to replace Webforms controls with something else from MVC. Just mix them - http://www.hanselman.com/blog/PlugInHybridsASPNETWebFormsAndASPMVCAndASPNETDynamicDataSideBySide.aspx
Well, I was also wondering how to use 3rd party controls in ASP.NET MVC. Obviously, and contrary to some answers here, it had to be possible.
As much time has passed since the question was asked, the industry has evolved. So I've searched and found (but havent' yet tested) solutions such as Telerik Extensions for ASP.NET MVC .
I'm posting this answer here mainly to support other MVC newbees such as myself - Just Google
"asp.net mvc" controls
We have questions about free .NET libraries and applications, but I'm curious about what ASP.NET control packages you've used that provide the best bang for your buck. Yes, paid stuff.
I'll get the ball rolling by saying I love the Telerik controls, but their price tag isn't great. The one reason I would say the value is the greatest here because of the licensing, which makes deployment so easy.
[Full Disclosure: I work at Telerik.]
I won't make any statements about which controls are the best- since clearly my opinions would be biased- but I will say that in the "3rd party" component market (in other words, not Microsoft and not open source) the pricing amongst the big players is all about the same. And in general, if you need the rich functionality offered by any of the 3rd party suites, the price is significantly lower than what you'd pay in your own dev time to rebuild the controls from scratch (or even to customize an open source control).
There are some significant differences in the way the licensing is handled, though, and as Josh originally highlighted, Telerik has the most open, "developer friendly" licensing approach. Purchased controls have no license keys to deal with.
Hope that helps.
I have both Telerik and DevExpress and I find myself, more and more, moving away from the Telerik stuff and using more of the DevExpress controls. I particularly like the DevExpress reporting package (the Telerik one was unusable) and the Grid / PivotGrid. However, Telerik does have better AJAX management helpers (although I no longer use them as I've learned enough about "raw" AJAX) and the Telerik Editor control is the best there is.
So...one vote here for DevExpress.
Telerik is by far the most robust for the cost; but you're right that the cost is a bit high.
We use the "Web.UI" suite from ComponentArt and we're very happy with it. You get the source code, redistribution, etc. Makes our web app stand out for sure.
http://componentart.com
The cost of Telerik's / DevExpress controls are CHEAP compared the cost having one or two people develop "something better". I have had developers work two weeks on just a grid with no Ajax, no client side anything and it looked like crap. Unless you have great skill with tools like jQuery and the team all possesses those skills, it is cheaper to go with a purchased library. Stuck on an issue, open a ticket. It's that simple.
Curious if others feel the same as me. To me, controls such as datagrid/gridview/formview/etc. are great for presentations or demo's only. To take the time and tweak this controls, override their default behavior (hooking into their silly events etc.) is a big headache. The only control that I use is the repeater, since it offers me the most flexibility over the others.
In short, they are pretty much bloatware.
I'd rather weave my own html/css, use my own custom paging queries.
Again, if you need to throw up a quick page these controls are great (especially if you are trying to woo people into the ease of .NET development).
I must be in the minority, otherwise MS wouldn't dedicated so much development time on these types of controls...
Anyone that thinks nobody uses *Grid controls has clearly never worked on an internal corporate webapp.
I'm pretty much writing my own HTML - I'm using the ListView and Masterpages, but not really using the controls much anymore. My ListView laughs at your silly old repeater, by the way.
However, bloatware isn't necessarily a bad thing. If I needed a low volume intranet application built, I'd much rather pay a less experienced developer to drag and drop controls than for an HTML twiddler (like you or me) to craft each tag. There's definitely a place for the quick, simple approach. What's the cost of "bloatware" in that scenario, as long as the control based code is written in a maintainable fashion? Often wiring controls together requires less custom code, which means simple maintenance.
The one place I have to disagree with you - pretty much regardless of the application - is in crafting your own paging queries. You may like to do that kind of thing, but there's absolutely no business value in it. There are several professional-grade DAL tools which will usually write more maintainable, faster queries than most developers. Even if you lovingly craft the perfect paging query, it won't keep up to date with changes to the schema unless you continue to throw hours after it. I think better use of those hours is to build a lightweight system and put those hours into monitoring and fixing specific bottlenecks, rather than immediately jumping to the "database assembly language" layer.
I've been reading your posts guys and it made me feel dumb.
I mean in every application I made where I work there is at least one datagrid/gridview in it. And I didn't have the feeling I am missing something.
Sure I find datagrid/gridview kinda bloated but are they that much disgusting to use?
I think you need to learn to use GridViews before you condemn them. I use them extensively. At first it was a bit challenging to figure out certain things, but now they are indispensible.
GridViews within UpdatePanel with AJAX CRUD and pagination are lightning fast. One of the larger systems set up this way (for internal/external application) has a moderately sized db in the backend. There are many nvarchar(2000) fields and the transitions and updates are great.
In any event, if you've written your own version of displaying data, you may want to continue using it if it works. (Same argument could be made for writing your own compiler, writing your own version of HTML, writing your own version of data access binaries...) The advantage of using GridView is that there are a lot of people who are familiar with it and that MSFT has abstracted/modeled the class to do a lot of things that we used to have to do manually.
Every single app we development at my company has grids (the apps are all behind the firewall). That includes both web apps and Winform apps. For the web apps it's the good ole gridview with custom sorting for the winform apps we use Janus grid. I'm trying to get the developers/users to think of a better user interfaces but it's a tough to change. I gotta admit its still better than the alternative of the users building their "own" apps with Access that I would then need to support!
Using controls like the GridView are great for simple apps. Even if you are a server-side HTML bracket-twiddling ninja, they can make developing simple stuff much less time consuming. The problem is that they usually start to expose their shortcomings eventually, and you end up having to spend time tweaking them anyway. But at least you can get up and going quickly to start out with.
For example, the default paging in a GridView doesn't support paging in the database itself (you have to load all the rows before it will page them), so once you start feeling that pinch in performance, you may need to think about rolling your own or, perhaps better, find a more capable grid control.
Anyway, the point is that pre-built components are good. They help. But as usual, it depends on what you need them to do.
I've actually used GridView extensively for an adminsitrative console. I even created a custom DataFieldControl that sets the field's header text and sort expression based on data field, creates an Insert row in the bottom and automatically collects the values in the row and forwards them to the data source's insert method, and generates a list box if an additional list data source is specified. It's been really useful though a huge time investment to build.
I also have another control that will generate a new data form based on the fields' metadata when there are no records (in the EmptyDataTemplate).
<asp:GridView ...>
<Columns>
<my:AutoField HeaderText="Type"
DataField="TypeId"
ListDataSourceID="TypesDataSource"
ListDataTextField="TypeName" />
</Columns>
<EmptyDataTemplate>
<my:AutoEmptyData runat="server" />
</EmptyDataTemplate>
</asp:GridView>
I really like the telerik radgrid. Their product ain't cheap, but you get a lot of controls and features. And the data binding support is pretty good, both in a simple asp.net data source binding way and in a more custom handle-your-own-databinding-events kind of way.
At my company we use grids everywhere, mostly ComponentArt Grid (http://www.componentart.com/). Yeah it's bloatware but you get a lot of functionality that wouldn't be much fun to re-invent: sorting, paging, grouping, column reordering, inline editing, templating (server-side and client-side). The client-side APIs are nice too.
I like the GridView control and have used it in several custom DotNetNuke modules for my company's web site. For one thing, using the built-in controls means less dependencies to worry about. And once I had it set up how I wanted it, I basically copied the code to other pages and just had to do minor tweaks.
I've found that there are so many options with modern grid controls (Infragistics, Telerik, etc) that it takes longer to configure the grid than anything else. The MS controls are pretty simple yet they can do pretty much anything.
They are one of the benefits of asp.net. Up until just recently I hated them, but the more you use them the easier they become, once you learn what setting you must change for which instances. Mainly I like the form view and listview the gridview still needs some work.
We use the Infragistics UltraWebGrid + LinqDataSource on our intranet apps.
It gives us ajax, sorting, filtering, paging all server side.
The "export to excel" also is a killer feature.
We have 5000+ users,lots of data, performance is excelent.
I largely abandoned grids once I started designing from user stories, rather than from database table requirements. And never editable grids. The old way was just how we coerced users into doing data entry/table maintenance for our systems, and it never matched their workflow - any real job ended up skipping from one master/child form to another.
And the users never figured it out - but they sure knew our applications were harder to use than they should be.
An exception is analytical applications. But there are relatively few of those, and they are largely read-only.
I too would like to see an expanded answer on why GridView et al are considered "bloatware." I have extensively used GridView as well as 3rd party products (Telerik, etc) and find that for the majority of internal and some external projects, they work great. They are fast, easy to use, customizable - and BEST - I can hand them over to someone who knows GridViews who can then easily pick up where I left off. If I were to hand-code all of the numerous apps/controls, the overhead in the next person figuring out what is going on would be enormous even under the best of circumstances.
For me, I can see some of the 3rd party products being bloatware (but still sometimes useful), but the bare-bones GridView I've found to be quite fast with moderate queries.
For my corporate intranet projects, grids are indispensable. They are the foundation for easy reporting on the ASP.NET webforms platform.
Easy to Design
Paste the grid on the page. Insert BoundField objects for simple binding. asp:HyperlinkField for easy linking.
Binding
You can bind grids in a handful of ways:
a collection of objects (List, ArrayList, Hashtable, or any simple collection)
SqlDataReader in your code-behind (yikes, that would require SQL in your presentation tier)
SqlDataSource (specify a stored proc. All the columns on the resultset map directly to the grid's columns. It's a very quick and dirty if the report doesn't mimic your domain object nicely. i.e. summations of different things.)
objectDataSource (binding to a method on your BL)
For those who might call out SqlDataSource and ObjectDataSource, you don't always have to have them declared in your .aspx.cs or .aspx.vb . I am not advocating them here, just pointing out the possibilities.
I don't think you can discount the RAD benefits of the built-in GridView and other 3rd party grids. Management types love and want tabular data.
Components like the GridView/FormView/DataGrid follow the 80/20 rule.
This means that 80% of the time when you use them for simple purposes they get the job done and are extremely easy to implement.
But 20% of the time you will be trying to build something complex (or weird) and you will be forced to jump through a dozen hoops and bend the code in many ways to try to implement a solution.
The trick is to learn whether the problem is an 80 problem or 20 problem, if you can identify the 20 problem early you are much better off writing the code from scratch yourself and ditching the "time saving" one.
I use them extensively in the corporate environment I work in and I'm working with one right now. The people who don't use them remind me of all those "I built it with Notepad" developers of years past. What's the point of using asp.net if you're not going to take advantage of the time savings?
I have never used it. I completely agree, it's bloatware. I usually end up using the repeater with custom controls that i made.
For anything long term I would try to avoid datagrid/gridview, it sometimes becomes too hacky making it do exactly what you want, after a certain number of these tweaks you start to realise its not saving time in the long run and you might not be getting the control over markup that you need.
However the built in paging and sorting functionality works well and in 2008 there is a new ListView control which aims to sort some of these problems out and give you tighter control of the html that is output.
I have wondered about this for a long time. There seems to be a consensus here that the grid controls are bloatware. But, can anyone definitively cite the cost of using these controls? Is there excessive HTML sent to the browser? Too much resource devoured on the server? Is generating the HTML table faster (assuming it's well-written)?
In addition to the bloatware issue, I have often run aground when UI requirements are enhanced to include features beyond the scope of the standard controls. For example, in early ASP.Net versions, I struggled with putting images in column headers. And, I believe it's still a challenge to add a second, top-level header row spanning multiple columns. At some point, it becomes really difficult to wrestle with the control to achieve the desired effect. And it's frustrating if you know the HTML you want, but you just can't make the control do it.
On one project, I finally gave up and wrote myself an HTML table class to generate a very complicated grid. It took a couple of days to get it just right. But, now I have the basic code, and it will be much more efficient to tweak that for future grids.
No doubt about it, though. It's hard to beat the fancy grid controls for speedy development, if you can just live within their limitations.
If you work with designers a lot on public facing web sites then you should ditch the GridViews and stick to repeaters. That's my opinion anyway - I've had to pull apart hundreds of GridViews and turn them into simple repeaters in order to fulfill the design requirements.
If you go near DataGrids or GridViews with a 10-foot pole on a public facing web site then you HAVE to use the CSS friendly Control Adapters. (At this point you might find it easier just to do it in the Repeater.) Prior to Control Adapters being available I would have considered these controls broken out of the box.
I find that too many .NET developers do not have a good understanding of design, accessibility, CSS, javascript, standards etc. which is why they succumb to GridViews, ObjectDataSources etc.
GridView is fine and very powerful control and works well with css or theme. The only thing that is annoying me is that VirtualCount property was dropped when old 1.1 DataGrid was replaced with GridView in asp.net 2.0 and it was useful for implementing custom paging. However same can be done via data adapters.
Though working with repeaters is maybe clearer and you have total control over rendered html still I wouldn't recommend going on that ways because is harder to implement and maintain.
I never really used the standard WinForms grid before but at my last job we used the ComponentOne FlexGrid extensively and it worked beautifully. There were still some annoyances with trying to get all the customization we wanted but overall it saved us a ton of time and produced beautiful results.
Currently I'm working with Silverlight 3 and RIA Services and I can't imagine trying to produce what we're doing without the DataGrid and DataForm controls. The time being saved far outweighs any of the overhead.
i am a moderate level developer i can say without these controls i couldn,t ever learn developing.just you have to admit yourself to it for a while till you find your way to customize it and the end result will be great
I'm trying to look at it all in context. I have a page that has a nice gridview (displays 10 rows at a time, 6 columns, sorting, and paging) and if I just look at the html table that is created along with the viewstate, I'm only seeing 29k of code.
Is 29k vs. 18k for using a repeater or listview really worth all the effort in these broadband times?
I personally stick with the gridviews however the design guy I work with sometimes gripes about trying to style it via css.
Just reading your posts. I agree PHP is easier than asp. but I just started using visual studio for formviews and gridviews. Can not get much easier for either vb or C# programmers. ASP still has problems uploading large files. PHP it's a snap. I run PHP under IIS 7.5