Opinions needed of the use of Code-behind

[Robby]

I created a couple of web-sites using ASP.NET....

In the original design (classic asp) they were about 20 HTML

pages and 20 classic ASP pages.

 

Now in .NET I have reduced it to one ASPX file, one Code-behind

page and a bunch of classes.

 

IF you have worked with ASP.NET what is your opinion of this

approach as compared to creating multiple ASPX pages?

 

 

Reason for my query? Their are many posts lately that ask how to

send data between ASPX pages. As you can see if you have only

one page, it is much easier to manage (and distribute)

[Daspoo]

Well, I'd probably vote for a single ASPX page and different classes, assuming all of the code that may be reuseable is contained in the classes. In other words, if there are multiple apps, or if you plan on creating new apps in the future that will apply the same type of functionality as this project, you would want everything that may be useful to those future projects in classes that clearly define parts of that functionality. I guess that's the ultimate goal behind object-oriented programming.

 

If you have multiple projects, for example, that involve people, it's more efficient to create a class based on a person, with properties like NickName, BirthDate, etc... Ok I'm rambling...sorry. I think a single ASPX page is the way to go if all of the code is clear and not just shoved together. :p

[Derek Stone]

re: Robby

 

Generally speaking it's a good idea to split up large projects into multiple parts, divided by functionality and purpose. It becomes clear after working on a sizable project that code separation is the only correct method of organization. Applications, including websites, become less scalable when they're confined to a single file, since changes to one feature often affect another. Making these code divisions is an absolute necessity if more than one developer is working on a project, however it becomes less important if the development is being done by a single person, or if the project is of a personal nature. Regardless, the industry accepted standard is to separate by application-- an application being defined as a set of pages or functions that operate together to perform a specific task. In the case of a website, we could define one application as "products" and another as "customer support", each one moving the site's users toward one focused end-goal-- either purchasing a good or service, or getting assistance with that good or service. Just like it doesn't make any sense to group a billing team with a customer support team, it doesn't make any sense to group their webpage counterparts as one either.

 

In your case, I can foresee you combining like pages (out of the 20-or-so you said there originally were) into 4-6 pages and their associated code-behinds. This creates a maintainable yet fairly compact website. And while I agree with you on your distribution comment I can't see how one page would decrease coding time or complications when it comes to data transfer. Care to elaborate on that?

[Robby]

It doesn't decrease coding time at all, the couple of sites I did in this fashion were

relatively small. Here's the basic structure�

The aspx file has one placeholder, and the aspx.vb page has all the event handlers as well

as a select case which handles all the classes (which are separate). The entire site can be

construed as one application, there are no sales or service.

 

When I started this thread I had not considered any sites as you described "Products",

"Customer Support"...etc. You're absolutely right with "it's a good idea to split up

large projects into multiple parts"

[Derek Stone]

Well that's the thing. The term "application" has to be scaled to accurately coincide with the size of the project being dealt with. If you feel that a site is best suited to fit into one application then that might just be the best solution. Nowadays though even personal websites seem to include their own forum, guestbook and t-shirt store (which disgusts me by the way) and each one of those deserves its own separate space. However, if all the site is serving is static content then the divisions usually don't have to be quite as clear.

 

I can express my opinion on this until I turn blue in the face, but it's up to you to decide. You have good judgement. Trust it. :)