When designing a ASP.net WebForm application what are some important steps to take (or hacks if you like to use the term) to ensure the best possible performance (in terms of speed, stability, and scalability)?
Here's a good Best Practices written by microsoft. Chapter 6 is specific to ASP.NET, but the whole document is .NET in general.
http://msdn.microsoft.com/en-us/library/ms998530.aspx
You've got a ton of material, directly from Microsoft here.
Also a checklist is available if you want condensed information.
Just a couple, in addition to the good advice already given,
Don't put every single page in a webform, not everything needs it - The default behaviour from VS is to give you a master page that wraps a form around everything, and a lot of people seem to stick with that. In my experience, some controls can render 30% faster outside of a webform, so if you're just parsing a querystring then reading something from a database, leave the form at home if you can. Even getting your navigation out of the form will help.
Don't use a server control when plain old HTML will do - does it really require a asp:linkbutton or asp:hyperlink just to go to the FAQ page etc. Plain hyperlinks work just fine in asp.net, but some people seem to get stuck on the idea of using runat="server" for everything.
There is a phenominal book on this subject by one of the Yahoo guys, Steve Souders. It taught me a lot.
Or you can just watch this video. It's a high level overview of the same information - you can pick up a lot in 45 minutes by watching this.
NOTE: This content is not WebForms-specific. It's general best practices for the web, and it is what you need if you are trying to roll out a high performance website.
Big # 1 tip: turn off viewstate in the web.config. That should have been the default, if you need it for a control turn it on on a control by control basis.
My other piece of advice is stay the hell away from *view controls. Use repeaters and find a good 3rd party grid control. The really "magical" controls that ship with asp tend to be perf hogs, and in general just not a good idea anyways (with the possible exception of ListView)
1 - Turn on content compression on iis
2 - Cache everything you can
This will do for the majority of webapps out there.
I am not sure about content compression when the content involves html with js doing ajax stuff. Sometimes the blocks of data exchanged through ajax are small and in this case (and if that is considered content) compression often hurts instead of helping. For example, a four bytes block of data produces a compressed block of 100+ bytes.
Related
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.
I’m new to .net, though I’ve been writing in classic asp for years. I know it’s time to make the change, but I can’t stand how bloated the HTML becomes.
For example, a simple menu using a web.sitemap and adds over 100 lines of JavaScript and HTML. A simple form with server-side validation adds in masses of ugly JavaScript. And a basic table of data using GridView adds in a ViewState that makes my eyes water.
Call me a purest, though I don’t like sending data to the browser unless it’s needed. And I don’t need a form-riddled menu when a simple unordered list of links will suffice.
So, set in my ways, am I destined to forgo the benefits of the Framework entirely by insisting on writing my own, cleaner code for everything? Or am I missing the point?
As a brief aside I’m a big fan of Campaign Monitor, a newsletter distribution company. They’ve written an elegant and comprehensive user-interface in .net without a single ViewState or bizarre .net-mangeled ID reference. Even the Sign Up form on their website (/signup.aspx) is as clean as a whistle. What’s their secret?
I hope I not the only one. Any advice would be greatly appreciated.
Try ASP.NET MVC or one of the other MVC web frameworks for .NET
If your GridView doesn't need it, then turn ViewState off for it.
Also, please edit your question to say what version of .NET you're using. Some of this gets better, and some does not. You might also want to try VS2010 beta 1, and complain about anything it doesn't fix.
Another idea would be to go on treating ASP.NET like it's classic ASP. Do it exactly the way you're used to, but do it with the idea in mind that there's about 10 years of development work that's gone into solving some of the problems of classic ASP. Once you actually hit one of those problems, find out if ASP.NET has solved it, and how.
For instance, I have a hard time believing you enjoy writing FOR loops to generate table rows. If you get tired of that, learn to use a Repeater control, or a DataList control, or even the old DataGrid control. If you turn ViewState off on those, I think you may find the generated HTML to be acceptable, and you'll find it a lot easier to generate tables and other structures that repeat based on repeating data.
You can opt-out of much of that bloat by not using all the out-of-the-box controls that come with it but I prefer the MVC route that activa suggested
Here is my list:
Keep the use of asp controls to minimum
Turn off Viewstate when it's not need
If you don't want the JavaScript associated with Client Side Validation (with ASP.NET Validation) set the EnableClientScript to False
Use asp:literal instead of asp:Label
Yeah it seems to be that everyone is bashing webforms at the minute for the reasons you have outlined above. HTML heavy Controls, ViewState, no control over ClientIDs all seem to cause an issue with people.
However let is be said that you can use asp.net (webforms) and produce some decent applications.
Control of html is yours through httpModules and httpHandlers and some of the issues mentioned above are fixed in asp.net 4.0
I just listened to a great podcast comparing MVC and webforms. Its in the area you are asking about. Also check out this blogpost by a dotNetNuke regarding the good asp.net code and why people should take a breath before converting everything to mvc.
Having said that I've tried Asp.net MVC and it is awesome. I'd probably look at dotNetNukes code to as its a mature asp.net product.
Also, when you do want to use these newfangled server controls, check out the css friendly control adapters. They clean up much of the bloat.
For client IDs the key thing to remember is to let the framework handle them. If you need to get an element on the client side, remember to emit the control's ClientID property into your script.
I've been using a template system and am very happy with it. Basically write an http handler for .html files and put tokens in the html files that regex could find in one sweep and inject any stuff. (google template c# for more info).
I tried some of the supposedly cool new features of ASP.NET for a little while. I also didn't like most of them. I felt constrained to work within the limitations of the common paradigms Microsoft had dreamed, even though I new how easy it would be to produce the HTML and JavaScript myself to do specifically what I wanted to do without having to learn how to jump through the hoops of so many new Microsoft-specific idiosyncrasies.
Anyway, I stopped using the parts of ASP.NET I didn't like on new code I've been writing lately. When I first started using ASP.NET, nothing in the MSDN documentation jumped out at me about how to avoid such complications, so I posted a couple "Hello, World" at http://www.agalltyr.com/rawaspdotnet.html to help spread the heretical word. I couldn't care less if it's the latest cool technology or the recommended technique. It's a reliable and reasonably efficient tool I can use to do my work.
Oh, and I'm not in the mood to learn ASP.NET MVC either. That's just more idiosyncrasies. Give me a language (C#) and a framework (.NET), and I'll design my own abstraction, thank you.
There are lots of articles and discussions about the differences between ASP.NET WebForms and ASP.NET MVC that compare the relative merits of the two frameworks.
I have a different question for anyone who has experience using WebForms that has since moved to MVC:
What is the number one thing that WebForms had, that MVC doesn't, that you really miss?
Edit
No-one has mentioned the WebForms validation controls. I am now working on some code that has a few dependant validation rules and implementing client-side validation for these is proving slow.
As a PHP/Classic ASP person, I ventured into webforms world about 5 years ago. After having to handcode things like table grids, calendars, etc, in scripting languages, it seemed like webforms would be a tremendous helping-hand. It was...that is until you need even a slight bit of customization beyond alternating row colors and the like. Yeah, you could have a gridview running with a few drag-and-drop motions. But customizing even what would seem like a simple thing could turn into hours of torture and research.
I also think a lot of the examples given in .NET online are oversimplified for the effect of making webforms look "easy". Sure you can get that gridview to show only 10 records of a 100,000 record table, but do you realize that ALL of the records are being loaded into memory by default? As an example of the over-complicatedness of rectifying that problem, I spent a while creating a pageable gridview that only loads chunks of records, but it wouldn't work. After an hour of research, I found that you had to delete an extra property that the IDE inserts into the codebehind. Not fun when stupid stuff like that sets you behind.
And at every turn, it happens.
Don't even get me started on viewstate.
But then the clouds parted, and .NET MVC was handed to us. Now THAT is a framework. If you are a web developer, you should know whats happening when someone makes a request to your webserver. The abstraction and layer of cruft that webforms put on top of that is a disservice.
For the most part, I'm able to develop applications at the speed of PHP scripting and FINALLY have TOTAL control over the UI. That's what it's all about.
And as an additional note: People need to stop complaining that they are creating "tag soup" in MVC views when they find they have to use <%= %> tags and the like. Drag and drop your gridview onto the page, set all the properties, then view the crap it gives you. And your not nearly done yet, now you have to attach events and put more gridview-related code in your codefile. Talk about messing up the coding experience. I'll take a simple foreach loop anyday.
nothing :)
I really like the way ASP.NET MVC works. I want to control my HTML. I don't need controls. We can get the same functionality with HTML helpers and third party tools, e.g. jQuery and all the available plugins.
Here's an example on how to use a gridview-like with jQuery grid on ASP.NET MVC.
Although Ruby on Rails is a more mature framework, I do think that ASP.NET MVC is on the right track.
I miss the gridview, the simplicity of getting built in sorting and paging in with very little effort. I use grid functionality all the time and have still not found a good alternative in mvc
Well I do miss something :
the ability to have a pageable grid in seconds.
Although it wouldn't be very fair since I also had to create a class to feed to the ObjectDataSource to have an efficient pagination. And also the pagination would work only with the JavaScript on or I would have to write code to read the QueryString (for ex. &pag=2 etc.) and so on.
In fact... I guess there isn't much too miss.
The simplicity of having only one form on a page. I think the html form functionality is kind of awkward and not very intuitive and I guess there is a good reason why the webforms creators tried to abstract away form handling in webforms.
One difference, which I am sure will be rectified over time, is the expansive amount of reference material and examples online for web forms versus the relatively sparse amount for MVC. However, one could argue that a lot of the material on web forms covers topics such as the page life cycle which MVC no longer makes necessary (thank goodness).
Until now nothing really.
I definitely miss MVC every day at work while I look at the ugly WebForms code I want to wipe it all out and now make everything transparent, clean and beautiful.
Of course only time will show whether the new girl is really better than your old wife.
As crazy as it sounds, I miss the calendar control. Not for datepickers or that sort of thing, but for scheduling apps where you want to show a full page month-at-a-glance/outlook style events calendar with selectable or clickable links that you inject via the day render event.
If anyone knows of an MVC alternative, please share! Rolling your own in this case is doable, but kind of a pain.
Viewstate is the thing i miss - until i remember problems it causes.
Then i bend my mind and look for another approaches (smarter model binding, ajax etc.) which usually turns out to be better (but slower to find & implement).
The main thing I miss is the documentation. WebForms, because of it's relative maturity, has a lot of official documentation and also a lot of 3rd party examples and snippets available. However, this is improving all the item and, as MVC gains momentum, I hope it will be on a par.
Nothing as well.
WebForms do so much automatically but frequently I had to hack it to suit my needs.
MVC let me do what I want and I can hack it to get things done better/faster.
I love to control the output and prefer clean, lightweight style.
Output Caching is not really implemented in ASP.NET MVC (as of version 2). There are tricks to get it working, like using Web Controls with the OutputCache directive, or using WriteSubstitution, but all these tricks go against the nature of MVC in some way. Output Caching for anything other than entire action methods is really tricky to get working in ASP.NET MVC, and always induces enormous technical debt. Since Output Caching, especially in the newer versions of IIS, is incredibly performant compared to data layer caching, this is a shame.
simplicity in Dragging and dropping controls.
might be seeing some of this in the near future maybe in mvc4
Reference :- http://www.codeproject.com/Articles/808297/Things-you-will-miss-in-ASP-NET-MVC-as-an-ASP-NET
I will not say i miss because all the changes are happening for good. But yes i would miss the below
The lovely server controls who just give output in a blink.
The behind code file.Double clicking and going to the Code behind for some reason made me superior.
Viewstate magic.
Now i need to get in to headache of POST and GET.
This sounds like a "why would you do that?" sort of question, but here goes..
I have a very simple ASP.NET page which simply renders out a one column grid of about 10 rows with paging.
At the moment, I need (due to some technical restrictions) to essentially host the ASP.NET page within an IFRAME on a basic HTML page. It works of course, although I wonder if there is a better way?
For some reason I am thinking something like silverlight (which I might end up using) being a container.. or some other ActiveX type control..
Hope this explains enough?
Thanks in advance!
You're right, this is pretty much a "why would you do that" type of thing. However, we all know that you don't always have control over what you would like to do thanks to managers who don't know jack about developing websites, etc :) as I've been in a similar position and been forced to do almost exactly the same thing.
Anyways, I believe the way you are doing it is about the simplest way to do it. The only thing you might want to keep an eye on (I don't know if you are running from separate domains, as the question doesn't specify) is cross-domain scripting. For example, if your ASP.NET page is at www.myaspdomain.com and your HTML page is at www.myhtmldomain.com, cross-domain scripting, or scripting between the IFRAME and the ASP.NET page can cause some interesting bugs (features?) because of the security holes that such scripting opens up and has thus mostly been blocked nowadays.
You might be able to use XmlHttpRequest to fetch the contents on ASP.NET page to an HTML element.
Although ASP.NET MVC seems to have all the hype these days, WebForms are still quite pervasive. How do you keep your project sane? Let's collect some tips here.
I generally try to stay clear of it... but when i do use WebForms, i follow these precepts:
Keep the resulting HTML clean: Just because you're not hand-coding every <div> doesn't mean the generated code has to become an unreadable nightmare. Avoiding controls that produce ugly code can pay off in reduced debugging time later on, by making problems easier to see.
Minimize external dependencies: You're not being paid to debug other people's code. If you do choose to rely on 3rd-party components then get the source so you don't have to waste unusually large amounts of time fixing their bugs.
Avoid doing too much on one page: If you find yourself implementing complex "modes" for a given page, consider breaking it into multiple, single-mode pages, perhaps using master pages to factor out common aspects.
Avoid postback: This was always a terrible idea, and hasn't gotten any less terrible. The headaches you'll save by not using controls that depend on postback are a nice bonus.
Avoid VIEWSTATE: See comments for #4.
With large projects the best suggestion that I can give you is to follow a common design pattern that all your developers are well trained in and well aware of. If you're dealing with ASP.NET then the best two options for me are:
o Model View Presenter (though this is now Supervisor Controller and Passive View).
This is a solid model pushing seperation between your user interface and business model that all of your developers can follow without too much trouble. The resulting code is far more testable and maintainable. The problem is that it isn't enforced and you are required to write lots of supporting code to implement the model.
o ASP.NET MVC
The problem with this one is that it's in preview. I spoke with Tatham Oddie and be mentioned that it is very stable and usable. I like it, it enforces the seperation of concerns and does so with minimal extra code for the developer.
I think that whatever model you choose, the most important thing is to have a model and to ensure that all of your developers are able to stick to that model.
Create web user controls for anything that will be shown on more than one page that isn't a part of masterpage type content. Example: If your application displays product information on 10 pages, it's best to have a user control that is used on 10 pages rather than cut'n'pasting the display code 10 times.
Put as little business logic in the code behind as possible. The code behind should defer to your business layer to perform the work that isn't directly related to putting things on the page and sending data back and forth from the business layer.
Do not reinvent the wheel. A lot of sloppy codebehinds that I've seen are made up of code that is doing things that the framework already provides.
In general, avoid script blocks in the html.
Do not have one page do too many things. Something I have seen time and time again is a page that say has add and edit modes. That's fine. However if you have many sub modes to add and edit, you are better off having multiple pages for each sub mode with reuse through user controls. You really need to avoid going a bunch of nested IFs to determine what your user is trying to do and then showing the correct things depending on that. Things get out of control quickly if your page has many possible states.
Learn/Grok the page lifecycle and use it to your advantage. Many ugly codebehind pages that I've seen could be cleaner if the coder understood the page lifecycle better.
Start with Master Pages on day #1 - its a pain coming back to retrofit.
Following what Odd said, I am trying out a version of the MVP called Model Presentation which is working well for me so far. I am still getting an understanding of it and adapting it to my own use but it is refreshing from the code I used to write.
Check it out here: Presentation Model
Use version control and a folder structure to prevent too many files from all being in the same folder. There is nothing more painful than waiting for Windows Explorer to load something because there are 1,000+ files in a folder and it has to load all of them when the folder is opened. A convention on naming variables and methods is also good to have upfront if possible so that there isn't this mish-mash of code where different developers all put their unique touches and it painfully shows.
Using design patterns can be helpful in organizing code and having it scale nicely, e.g. a strategy pattern can lead to an easier time when one has to add a new type of product or device that has to be supported. Similar for using some adapter or facade patterns.
Lastly, know what standards your forms are going to uphold: Is it just for IE users or should any of IE, Firefox, or Safari easily load the form and look good?