if you are the only
I disagree strongly. How is it overkill? Please elucidate.
Just to set the balance straight, I agree with the OP. I am a sole
developer and find code-behind makes life more complicated. Having all
the code in one file is much easier. That's not to say there aren't
advantages to code behind, but it's not as clear cut as you are making
out.
How horrible! 6 to 8 open files! Sorry for being facetious, but that's a
very weak reason if one at all.
You are being unquestionably facetious and assuming that *your* style of
working must be the best for all. If you have several pages open at once
and you want to flip between HTML and code, then code behind forces you
to switch to another file. This can be quite disturbing to the mental
processes as you have to take your mind off the task at hand to deal
with the excise of switching windows.
Again, I'm not offering this as an absolute triumph of code-beside, but
it is a consideration, all other things being equal. Again, maybe your
working style doesn't have a problem with switching files so often, but
for many people this is distracting.
Why? It just makes extra work.
Yes, you should. Aside from your gripe about multiple open files you
haven't mentioned any reasons which would indicate that code-behind is
inferior in any situation. Code-behind separates data gathering and business
logic from presentation and is INCREDIBLY valuable.
In certain situations, yes. You are stomping your opinion on everyne
else's and assuming that the specific case(s) that you offer make
code-behind the only choice for everyone in every situation. This is
simply not true. You have to deal with each situation on its own merits.
Obviously there are advantages to code-behind, but there are advantages
to code-beside too, and you have to look at both before deciding. You
simply cannot lay down a blanket rule and say one is better.
Just to illustrate my point, let's say you are gathering data about
customers for a data table to distribute to your users. If your code is in
the ASPX, then sure, it might be faster to just pull all the data there and
be done with it (although my opinion is that it would take longer. ) What,
then, about when your users want the data in a different format? Say,
instead of a rows/columns datatable, a large detail format depicting each
item in full? Would you copy and paste the ASPX code, reformat, and make a
new copy of your page? If the data later changed, then you now have to
change your data gathering code in two places.
No, you would have the data gathering code in a separate module. This is
nothing to do with code-besides vs code-behind, this is reuse of code,
which can also be done with code-beside. You are implying that all of
the code for the page needs to be reused. In your example, only a very
small part of the code is going to be reused. That small part could be
put into a separate class, but you don't necessarily have to put all of
the code for the page separately as well.
Again, I'm not saying you shouldn't use code-behind, just that your
blanket rule is too simplistic to be useful. The case you give could be
done either way, and I don't see a huge benefit to code-behind from the
reuse of such a small piece of code, especially when that can be reused
either way.
In the same case, were you to have relegated the data gathering to a
codebehind you could have pushed that to its own class, separate from even
the page's codebehind, and simply coded a new ASPX page, included the class,
and bound the data.
Which you can do even with code-beside.
You could have picked a far better example if you wanted to champion
code-behind. Yours is hardly a killer argument.
And before you provide a better example, I would point out yet again
that it depends on the specific situation. Sometimes code-behind is the
obvious choice, sometimes it's just adding extra work for little or no
benefit.
Not using codebehind is ignoring one of the largest benefits of the dotNET
architecture, IMHO.
You're entitled to your opinion, but please don't state it as fact. Not
using code-behind *could*, in some case, ignore a big benefit of .NET,
but in other cases it would not make much (or any) difference. In some
cases it even makes more work.
And yes, this is *my* opinion, stated as opinion and not fact ;-)
