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, Id 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 thats the ultimate goal behind object-oriented programming.

If you have multiple projects, for example, that involve people, its more efficient to create a class based on a person, with properties like NickName, BirthDate, etc... Ok Im 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.

 

[Derek Stone]

re: Robby

Generally speaking its 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 theyre 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 sites users toward one focused end-goal-- either purchasing a good or service, or getting assistance with that good or service. Just like it doesnt make any sense to group a billing team with a customer support team, it doesnt 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 cant see how one page would decrease coding time or complications when it comes to data transfer. Care to elaborate on that?

 

[Robby]

It doesnt decrease coding time at all, the couple of sites I did in this fashion were
relatively small. Heres the basic structure

 

[Derek Stone]

Well thats 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 dont have to be quite as clear.

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