ASP.Net - Creating a web application that performs well? [closed]

It's difficult to tell what is being asked here. This question is ambiguous, vague, incomplete, overly broad, or rhetorical and cannot be reasonably answered in its current form. For help clarifying this question so that it can be reopened, visit the help center. Closed 11 years ago.

I need to create an ASP.Net application that deals with large amount of data, and performance is really important.

• Is it a good idea to use ASP.Net controls such as GridView, RepeatControl, SQLDataSource, etc? Are these elements designed to perform well, or am I gonna lose performance to use pre-made and easy-to-use elements?

• Which one is the proper way to deal with data? Creating a business layer and use business objects to populate form? or use the DataTable and DataSets directly?

• 开发者_StackOverflow社区Please give me some tips that is going to help with performance?

---

The biggest single piece of advice I would give is to first build your application using good programming practices, and then use a profiler to see what is taking the most time in your application. If you start out trying to make everything go as fast as possible you will waste all your time on things that don't really matter. On the other hand, if you start out making your code maintainable and following SOLID principles, you will find that it is easy to make drastic improvements by changing just a few pieces of code.

It is also important for you to define just what your targets are in terms of performance. At what point does a page load "fast enough?" Strive to make your performance targets, but don't go overboard in trying to shave 10 more milliseconds off an operation that users will only do once per month.

That said, you will find that the biggest time wasters are:

1. Round-trips between you and the user.
2. Sending large amounts of data between you and the user.
3. Round-trips between you and the database.
4. Retrieving large amounts of data from the database.

Here are a few general tips to optimize the items listed above:

1. Use MVC. It'll make it much easier to pass a minimum amount of data back and forth between the browser and the server.
2. Use unobtrusive javascript techniques so you don't have to waste bytes on every single page with repetitive scripts. Put your javascript into a static .js file that can be minimized and cached.
3. Use a CSS file to style your page. Set it up to be minimized and cached as well.
4. For icons, use a utility like jquery-ui so that there is only a single image file to download.
5. Set up your server to use proper caching and gzip techniques.
6. Use an architecture that makes it easy for you to cache data that is required often.
7. Be wise in how you access data. Try to load everything you'll need for a given request in as few round-trips as possible, and avoid loading data from the database that you won't need.
8. I essentially agree with everything fdfrye has listed in his answer.

One last minor thing to consider is that the next version of Entity Framework will automatically cache compiled queries, which will make most queries significantly faster without any extra work on your part.

---

As far as performance in concerned, your best bet is to go with ASP.NET MVC to avoid the page size overhead generated by the ViewState.

In and of itself, MVC won't make your application performant, but it will definitely allow more flexibility than ASP.NET WebForms will when it comes to squeezing out those last few milliseconds of lag.

As for data interaction, you can use any number of grid controls etc (jqGrid, mvcContribGrid, the Microsoft MVC Grid...) but they are all basically the same as far as performance.

Definitely create a separate business layer from your controller layer (again, if using MVC). Depending on your style you may include validation in your business layer, or in your model classes themselves.

Though Entity Framework is the best thing going as far as data access goes in a contemporary MVC app, you should watch out from a "batching" perspective. EF is still not great when it comes to bulk updates/deletes.

Bulk inserts should be reasonably performant, but still nothing compared to something like XML Bulk Load.

If necessary, use EF but couple it with the manual execution of parameterized queries which can still be executed using the same ObjectContext (rather than wiring up all the plain-old ADO.NET stuff)...