i have very strict requirements for performance on a large data entry application. You can imagine a single form with hundreds of fields, tabs, modal popups and similar.
The question is, what is the best Ajax architecture that i can implement to make it fast?
i was thinking about lightweight json async calls on the client, and async operations on the server. I was also considering HTML templates on the client, instead of building html on the server.
Let me know what you think.
Thanks in advance.
Use a combination of jQuery and HTML for the client and .net methods in the server-side callbacks. Async calls are good, but not always the best choice, remember that. Basically, use as few server-side components as possible because it generates much markup
there are also techinques for improving performance like caching. This can be done many places, for example on the .aspx page or on the web-server itself.
If you can, turn off the viewstate. This can generate much unnecessary markup
I would use a combination of JQuery ajax and ASP.NET MVC 3. These two combined provide an easy way to make fully async applications and due to the nature of MVC you can have HTML templates, most of which are already available through the MVC3 template.
Ok, I hate to say it.. but what you want is impossible. You cannot have a form with hudreds of elements on it, and still have it perform well. Of course "perform well" is subjective.. but the only way to get good performance over a high latency network connection with variable bandwidth (like the internet) is to work with very small sets of elements.
Using AJAX-Enabled WCF Services, JQuery and JQuery Templates can give you a good network throughput performance and a good user experience for your users.
But this comes with a price. Developing, debugging and mantaining such an application is very hard considered to a regularly developed ASP.NET application.
It's a trade-off, and if you ask me I would suggest you to go for the traditional way and make some improvements to your application interface, such as dividing forms, implementing a save-continue wizard-like type input screens. You can still use JQuery to improve user experience and caching to improve application performance. Keeping an eye on view-state and using UpdatePanel's as necessary could help even more.
In my application, I have a situation wherein the users will need to have the flexibility to customize the UI to a certain extent. The following are some of the customizations that is being discussed now...
Change Label text associated with the with Use Input controls
Mark a control as Mandatory/Read only/Hidden
Assign a regular expression for the text box
Are there any recommended design patterns for my situation? Seems like I need to store all these in a database and worried about the performance impact if I have to read every element from the database for every page.
Thanks,
Harsha
I would look at some of the open-source CMS or portal systems written in ASP.NET and see how they are doing UI customization (if they are).
Phil Haack has some insight at the following article:
Scripting ASP.NET MVC Views Stored In The Database
http://haacked.com/archive/2009/04/22/scripted-db-views.aspx
Apparently it's not an easy thing to do in ASP.NET. It's easier to do in ASP.NET MVC, because the markup is cleaner and you can control it with jQuery.
The overall concept you are going for is not easy to have system wide, however the specifics you stated are fairly easy.
You'd have to setup some fields in a database for those values and then on the page load set those values on the page load. Pretty trivial from a 'how to'. Which your question shows that you 'get'.
Now unless you are using an Access Database :-), I don't think you have to worry about the performance hit. But if truly concerned, put some caching logic on those values so you only have to hit the database once. Though, be aware this will store the values in memory on the server, so if you are working with a very minimal hardware this could be an issue as well.
A few guys on our team are of the opinion that every web page in the application should be a web user control. So you'll have all of your html + event handling in the Customer.ascx, for example, and there will be a corresponding Customer.aspx page that contains Customer.ascx control.
These are their arguments:
This practice promotes versatility, portability, and re-usability.
Even if the page is not re-used right now, it might be in a future.
Customer page might need to move to a different location or renamed sometimes in a future and moving user controls is easier.
This is a recommendation by MS for new development.
Is this really a recommendation for new development? Are there any drawbacks to this strategy? I agree that it's nice to have a user control on hand if the need arises, but it seems to be an overkill to do this to the entire application "just in case we need it later".
1, 2 & 3: Doing anything because "you might need it later" is a horrible strategy.
http://c2.com/xp/YouArentGonnaNeedIt.html
4: I have never read this and seriously doubt MS has ever said anything like this. Maybe some random article by one single person who has an MS tag or was an MVP or something, and a gullible junior dev took it as Gospel Truth.
Seriously complicates client-side script as the NamingContainer jiggery will prepend _ctl0 etc to everything sometimes.
I don't think MS ever recommended it. Request links to MSDN documentation.
Typically by the time your are done implementing something, and it is sufficiently complicated, you'll find a lot of "gotchas" when ever you try to "reuse" it. A good example is relative links in the user control that no longer work outside of their path.
Users don't need the ability to add/edit/delete Customers on every page. Indeed, you start to get into caching issues if you have these types of controls on every page. For example if on an Invoice page, you add a Customer, will the Invoice control be updated with the new Customer? All sorts of inter-control operability issues can manifest. These issues are hard to argue for, because of course, everyone's user control will be perfect, so this will never happen. ha ha right.
See if they can come up with an example where moving/renaming a user control actually saved time, instead of making it more complicated. Draw up an actual example and show the pros/cons of each.
Personally I'm not a fan, I think it adds a layer of complexity to the application that is not strictly necessary at the early stages. If you need to reuse a component that you had not previously thought would be reused, refactoring it into a user control at that point should not be very difficult.
I came across an application in .NET 1.1 that was written like that once. Someone must have heard that same misguided "best practice" and taken it for the absolute truth.
I agree that it adds a level of complexity that's mostly not needed. I usually find usercontrols more useful for something like portions of a page that are repeated on several pages. If you think you'd reuse the entire page... why not just use the original page?
I also don't understand the moving/renaming argument. It's not that difficult to rename/move a page. If you do what your colleagues are suggesting, you'd end up with a customers.aspx page that contains nothing but an orders.ascx file? I see more potential confusion/errors with that approach than by just renaming/moving a file.
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