Why I prefer inline code to code-behind

[neilmcguigan]

I just wanted to list some reasons why I prefer inline code to
code-behind.

1. you can fix some bugs more quickly. remote desktop into server,
change the aspx file, and she's good to go. I'd say this is one of the
major reasons classic ASP became so popular.

2. don't have to upload the large codebehind site DLL to fix one bug.

3. updating the codebehind site DLL restarts the application. fixing
one aspx page does not. (um, i think)

4. one file to upload, not two.

5. if you manually add a runat=server control to the aspx page (ie not
from toolbox), you have to add some more stuff to the codebehind page
manually, but not with inline

6. the code/html separation thing is pretty bunk in my mind. if all
code is in a script tag at the top of the page, and all html is below
it, that's separate enough for me.

7. MS added better support for inline code in 2.0, such as
intellisense, so they obviously are going to support it in the future.

 

[Marina]

To be honest, I think the reason your prefer it, is because you prefer ASP.
And ASP allows people to be much more hacky in their approach to
programming. It's just a bunch of script thrown together, often with little
to no structure. Where ASP.NET takes more discipline, if you will. And it
takes the correct approach and mindset to be successfull in it. In fact, I
would recommend people forget everything they know about ASP when starting
with ASP.NET. It always seems that ASP gets in the way of doing things the
'right' way in ASP.NET because it is hard to let go of old habits. It feels
like those that didn't know ASP before starting ASP.NET have a much easier
time picking it up.

Here are my responses to your points.

1. Most applications would use a source control system that would require a
checkout. Then, one would do a build of the application and redeploy that.
Not only do you have source control and history that way, you also have
builds that you can do at any time.
2. I don't think everything should be all in one massive projects. A large
application should be broken up into logical pieces, with business logic
being in separate class libraries, etc. This way no one piece is overly
large that its size makes a difference when uploading.
3. Ok yes. But, if one is doing a build, then it does not matter, since
odds are other things have changed as well. Additionally, after some number
of copying the .aspx files over, I believe the application restarts anyway.
So this approach is not full proof.
4. If you are only fixing the code behind, the only file you need to upload
is the DLL. You do not need to upload anything else. And if you made changes
to the UI as well - so what? Who cares if you have to upload 1 or 2 files?
Besides, you would be doing builds anyway, so this would not be an issue.
5. So add the objects from the toolbox so that VS.NET does the other stuff
for you. If you do everything manually, that may envolve multiple changes.
However, I have found that going into design mode in the .aspx, and
switching to code behind, VS will put the object declaration in for you.
6. That is unfortunate. I don't think you really see the power of separation
and reusability as far as code maintanability and speed of development on
future modules and projects.

 

[neilmcguigan]

I've used both for a long time and definitely prefer ASP.Net.

1. yup source control and a build process are good. But if you're on a
busy site and have to fix a bug Yesterday, it's going to be faster with
inline.

2. yup, having a data layer is good. but a site with 1000 pages is
still going to have a big codebehind DLL, even if the data layer is in
another project.

3. my theme was kind of "fix one bug really quickly".

5. how do i add a runat=server title element from the toolbox?

6. what does separation have to do with reusability? if my logic to
control a datagrid on a certain page is in another file vs at the top
of the page, that doesn't mean it's more reusable. How is moving some
code from a codebehind file easier than moving it from inline?

how is physical separation of the code and html better than logical
separation? (other than having a different desginer and coder, which we
don't)

 

[Edwin Knoppert]

I agree, my colleague does exactly the same.
He did ASP for a few years now.
The whole VWD settings are demolished to old unformatted style like captial
tags and indents off etc..
(To bad it isn't notepad i can read that in his mind )
Everything goes directly in the html code, i hate it!
I love the server/client code seperation!
Only a few obvious things are required in HTML with ASP.NET tags.

Well, i'm not a good HTML/website builder, i'm more the server-side
I never use CCS for example, well i believe that's a sin ?

I did only CGI and finally dotnet gave me something i can actually work
with!!
I desp. awaited v2.0 and worked with the beta's.
Never v 2003 or so.

 

[Edwin Knoppert]

CGI.. i meant CGI executables.
Simple tasks only.

 

[Edwin Knoppert]

6. well, if i may.. something like classes is of course much better.
Not really codebehind but both deliver more structured programming right?
Having a codebehind might lead to code separation as well.
I mean, someone might decide to no longer fill and cluther the codebehind
and go for classes right away.
It's way of thinking.

 

[neilmcguigan]

there's nothing in code-inline that prevents you from using classes.

for the record here, i'm not talking about interspersing html and
asp.net code, i'm talking about keeping all the asp.net code in a
script tag at the top of the page.

 

[Bruce Barker]

you will love vs2005 which is designed to work this way. it was the orginal
default, but the default was switched to codebehind for vs2003
compatibility.


-- bruce (sqlwork.com)

 

[Kevin Spencer]

Here we go again, arguing the merits of 2 methodologies as if they were
somehow mutually exclusive. So, if I may, let me attempt to reconcile and
remarry the two. After all, it is nearly Christmas. ;-)

An ASP.Net application, like any user application, has a user interface. It
also has business logic, and may manipulate data from a data store. Like
most applications, it will benefit the most from a tiered approach, having
at least an interface tier, a business tier, and possibly a data tier. The
separation of these tiers lends itself to reusability, as the same business
logic, for example, may be exposed in more than one interface, be it a web
application, Web Service, desktop application, or even a programming API for
use by other applications.

Within each of these tiers, subdivisions may be logical, again, for the
purpose of reusability. The user interface may contain Controls which might
be useful in other similar applications. The business layer may contain more
generic business functionality that might be applicable to more than one
type of application.

Now, in the case of an ASP.Net user interface, we're talking about ASP.Net
pages. There is a good reason for the templated design of such pages. They
are easier to maintain and extend. One can make a change to a single part of
the application without having to recompile the entire thing, in fact,
simply by swapping out a part. And the monolithic assembly model was not
particularly conducive to this model. So, the new inline code, with no
monolithic assembly is a good thing, no doubt. And, as has been pointed out,
assemblies can be referenced and used in this inline code model. As to
whether classes can be used, well, almost everything in .Net is a class,
including a Page. But certainly, one can use compiled classes in assemblies.
Otherwise, it would not be possible to use WebControls and HtmlControls in
an ASP.Net 2.0 application.

But is it wise to put *all* of the application code in the pages themselves?
Most often, I would say not. And I seriously doubt that anyone at Microsoft
would recommend this practice. Instead, business logic should be separated
out into separate classes, which can be used as assemblies (DLLs) or as
scripted components, but separate from the Page components. Personally, I
would prefer to use them as assemblies, as an assembly is a single file that
may be compiled from many source code files. It is simpler to manage, and to
re-use in multiple applications. I would say the same regarding the
development of re-usable interface Controls. Like WebControls and
HtmlControls, I would compile them into assemblies.

In the end, I believe this makes for the best of both worlds. You have Pages
within an application separated nicely, no monolithic assembly and need to
recompile the entire application, and you have your DLLs, with compiled
re-usable, and tiered components in it. Good OOP, good for business, good
for detectives everywhere.

Merry Christmas!

--
HTH,

Kevin Spencer
Microsoft MVP
..Net Developer
You can lead a fish to a bicycle,
but you can't make it stink.