ASP.NET application design aproach

Hi

I've just graduated from ASP to ASP.NET. I'm currently working on a project that serves as a front end to an SQL SERVER database.

The aproach I have taken is to put everything, from the login screen to report generation on one page by placing each of these sub components in pannels and showing and hiding them when necessary.

In ASP, I would use several different pages for each of these and post the data to a page that processes them and generates the result.

My question is whether the aproach I have taken with ASP.NET is the right way to go and whether there will be any performance losses caused by placing everyting on one page.

P.S. I am writing my scripts in VB.NET.

It depends on the way ASP.Net handles the visible property. If the property actually tells ASP.Net to render nothing then, damn thats a good idea. If not the page could take awhile to load. Is it loading quickly? DO a test with just one panel on a page and your full page and see how much diffrence you can see in load time.

Also if all your panels bind data you will want to insure that the control is only bound when it is display to the user. I'm not going to go into but there are issues about data caching and multi copies of data when using a dataset in combination with a data grid. Try to use DataReaders whenever you can.

Thanks for your response Magius.

The ASP.NET engine only renders the visible pannels so the amount of HTML code being sent back is small.

From my understanding, the code behind page is compiled into a dll that is called by the ASP.NET engine to process the page.

I was wondering whether putting all my components on one page will result in the dll size increasing therefore using up more memory compared to an application with multiple pages.

And also whether a new instance of thils dll is created every time a new session starts (when one more user logs in).


P.S. Do you have any information on the use of caching to efficiently manage the data being queried from the database?

Quote:

---

Originally posted by sunilja_2000
Hi

The approach I have taken is to put everything, from the login screen to report generation on one page by placing each of these sub components in pannels and showing and hiding them when necessary.

In ASP, I would use several different pages for each of these and post the data to a page that processes them and generates the result.

My question is whether the aproach I have taken with ASP.NET is the right way to go and whether there will be any performance losses caused by placing everyting on one page.

P.S. I am writing my scripts in VB.NET.

---

Well, I would shoot you for putting everything in one page if I had to take over a project that did that.

I think you should generate enough pages to keep things simple.

In my web application, there is ONE page out of 70, that holds about 15 different panels. In that one case, it was really necessary.... it was a data entry page for inputting people(names, description, alias, distinguishing features, their associates, picture, etc).

That one page is also the one page I absolutely disgust having to go back and change even in the slightest. It is also the slowest performing page in my app.

There is no penalty for having 3 pages over 1. Disk space is cheap. So if you use more than 3 panels in one page, your pushing it in my opinion.

A site I'm working on has message system. Diffrent Message types have diffrent info that goes with them. I am going to use panel to hideshow the needed controls for each type of message. This gives me four pages instead of like 30. 1Create, 2View,3Edit,4Delete. It is always a bad idea to let people view, edit, create, and delete in one place because well, people tend to click the wrong button...... and I never want to call ROLLBACK I want it gone because it should be not because they screwed up......

The thing I dislike is that I have Message Table a Message Type Table and then a Table for each type of message that has info besides text....... I mean it's good it will flex with me and new message types can be made easy enough by a dba or programmer, but I would be hard pressed to give the admin user the ability to add a message type that need more then just a TextMessage field....... ramble, ramble,....... I could but then I would have to make some kinda CREATE TABLE @GUIDConcatWithTypeName( @Cols); or something

Just a tip when designing web pages, think object oriented.. try to find out things that are the same for pages, group them, write base page classes and inherit! And don't forget the user controls! Great stuff in asp.net!

kind regards
Henrik