Code Behind vs not

[tshad]

I am just trying to decide whether to split my code and uses code behind. I
did it with one of my pages and found it was quite a bit of trouble.

I know that most people (and books and articles) like it because you can
split the code from the design. That is logical. But if you are the only
one working on the code, it seem a little overkill.

I use Dreamweaver to do my design and find it a bit of a hassle to have
multiple files open for each of my pages as I am working on them. I
typically have 3 or 4 pages open at one time that I am working on which
translates into 6-8 files open.

If I add an object to my design page I need to go the codebehind page to
define it there. If I was working with multiple people on a page, I would
need to run over to the person working on the codebehind and tell him to add
the new object to his page.

Things that are assumed on the .aspx page are not assumed on the codebehind
and have to be explicitly defined.

None of this is really talked about when codebehind is mentioned. Normally,
you are told that it is better. Is this the case in all situations?

Just trying to get other opinions on this, as I have already have about 30
pages designed and am trying to decide if I should split the files or not.

Thanks,

Tom

 

[Karl Seguin]

Tom,
I think you have some valid points against codebehind. If you are 100% sure
that you'll be the only one developing the site and you are 100% sure that
won't change or that things won't get a lot more complicated (say like when
I do my dad's website), then I agree the benefits of codebehind aren't as
significant. having said that, using Vs.Net you get great intellisense in
codebehind which pretty much makes it worthwhile just for that. Personally
I'd recommend you use it because I'm an OO bigot and love tiered
architecture but if it works for you without it, then by all means. You
seem to have a fairly good understanding of why you'd want to use
codebehind...so you seem in a good position to decide if it's good for you.

Karl

 

[Guest]

Separate them will make looking at your code easier, especially when you have
large file. Visual Studio.NET has good support for code behind so that when
you modify the UI, some of it is reflected in the code-behind file as well.

 

[Juan T. Llibre]

Please read the thread with subject :

"What's the difference/advantages
between code behind and code inside?



Juan T. Llibre
ASP.NET MVP
===========

 

[WJ]

I use Dreamweaver to do my design and find it a bit of a hassle to have

I heard the new version of Dreamweaver can handle Asp.Net page. May be it is
worthwhile to consult with the guys there to see if it is so.

John

 

[tshad]

Please read the thread with subject :

"What's the difference/advantages
between code behind and code inside?

I did and added my 2 cents worth - which is about all I can handle at this
point.

So far, I've determined that there really is no discernable benefit from
going from code-inside to code-behind (other than to use VS) or are trying
to hide the source if deploying the application. It really is a matter of
preference. Not a better way to code - as was mentioned.

Thanks,

Tom

The separation happens whether or not you use code-behind

 

[Juan T. Llibre]

This isn't, by any means, the end of this topic.

In ASP.NET 2.0, partial classes will add another element
to the current compilation model : partial classes.

See http://pluralsight.com/blogs/fritz/archive/2005/01/18/5111.aspx
to get up to speed with partial classes.

Make sure you follow through on the
comments after all the demo code.

There's an interesting discussion going on.



Juan T. Llibre
ASP.NET MVP
===========

 

[Kevin Spencer]

Tom,

Maybe you feel this way at this point in your career. Maybe you only work on
small applications. But, like good architecture, your methodology should be
extensible. Extensibility, and ease of code maintenance are the chief
reasons for separating an app into separate tiers, and separating HTML
template layout markup from Page business logic. At some point, hopefully,
you will work on large-scale apps, and/or work in a team, and I hope your
methodology can accomodate the new situation when and if it comes.

--
HTH,

Kevin Spencer
Microsoft MVP
..Net Developer
Neither a follower nor a lender be.

 

[tshad]

Tom,

Maybe you feel this way at this point in your career. Maybe you only work
on small applications. But, like good architecture, your methodology
should be extensible. Extensibility, and ease of code maintenance are the
chief reasons for separating an app into separate tiers, and separating
HTML template layout markup from Page business logic. At some point,
hopefully, you will work on large-scale apps, and/or work in a team, and I
hope your methodology can accomodate the new situation when and if it
comes.

Actually, I have been around for a long time and have rarely found a "best"
way for anything. Most times there are best ways depending on the
situation. There is a saying: give a programming task to 100 programmers
and you will get 100 programs. Some will be bad, but there will not be a
"best", but many good programs.

I am not saying that breaking an app into separate tiers is not the good way
for the situation you mention, but it is not a Panacea for all situations,
either.

I agree that breaking up code into objects and libraries is a good idea (and
I do it all the time) - but not for everything.

I am just trying to see the pluses and minuses I may not have come up with,
before I go in one direction or the other.

Always a good methodology.

 

[Kevin Spencer]

Actually, I have been around for a long time and have rarely found a

"best" way for anything. Most times there are best ways depending on the
situation. There is a saying: give a programming task to 100 programmers
and you will get 100 programs. Some will be bad, but there will not be a
"best", but many good programs.

I have to disagree. There are many ways to write a program, but only ONE
best way. If you don't shoot for it, you'll never get close.

--
HTH,

Kevin Spencer
Microsoft MVP
..Net Developer
Neither a follower nor a lender be.

 

[tshad]

I have to disagree. There are many ways to write a program, but only ONE
best way.

Based on who?

If I have a choice between the most efficient and the most readable and
maintainable - the best way is not necessarily going to be the same.

Programming has evolved over the years with "many" best ways and there are
differing arguments on what is the best. Just as you have disagreements on
whether MS is better than Linux or a Ferrari is better than a Volkswagon.
It depends on your situation.

You look at your options and pick the best based on your needs and
resources.

 

[Kevin Spencer]

You look at your options and pick the best based on your needs and

resources.

Didn't you just say that there wasn't a "best?"

--
HTH,

Kevin Spencer
Microsoft MVP
..Net Developer
Neither a follower nor a lender be.

 

[tshad]

Didn't you just say that there wasn't a "best?"

No. You said that. You said there is only ONE Best way.

I said there are many ways. As I said - "best based on your needs and
resources". What is best for me is not necessarily what is best for you.

Back to my car scenario.

Let's say I have a small income. Therefore, the Ferrari is not the Best car
for me.

My only point here is that you can't say that one thing (whatever that is)
is the best for everyone.

I agree with you that structure is the better way over non structured. But
you can be structured without splitting files. That is what code-inside
asp.net has over asp.

You can write very bad code using separate files and really good code-inside
files. Splitting the files doesn't make it better code.

Just because you can DO something doesn't mean you SHOULD do something.

 

[Kevin Spencer]

No. You said that. You said there is only ONE Best way.

Nope. YOU said "THE best" - the definite article indicates a singular
reference.

--
;-),

Kevin Spencer
Microsoft MVP
..Net Developer
Neither a follower nor a lender be.

 

[tshad]

Nope. YOU said "THE best" - the definite article indicates a singular
reference.

Only if you take it out of context - as you did.

"If I have a choice between the most efficient and the most readable and
maintainable - "the best" way is not necessarily going to be the same"

Not singular here.

"My only point here is that you can't say that one thing (whatever that is)
is "the best" for everyone."

Not here.

"You look at your options and pick "the best" based on your needs and
resources."

Not here, either.

Also, "the best" can change as circumstances change. (not singular)

 

[Karl Seguin]

By the time you two settle this partial classes might be 4 years old...

I always find quoting the simpsons in such matters helpful:

"And so, Gary Coleman and the Simpsons argued long into the night, and
then, as day broke, the spirit of the season entered their hearts.

'Lets just agree that the commercialization of Christmas is, at best, a
mixed blessing' "

 

[tshad]

By the time you two settle this partial classes might be 4 years old...

I always find quoting the simpsons in such matters helpful:

"And so, Gary Coleman and the Simpsons argued long into the night, and
then, as day broke, the spirit of the season entered their hearts.

'Lets just agree that the commercialization of Christmas is, at best, a
mixed blessing' "

I agree, but then you miss the fun

Tom

 

[Kevin Spencer]

Heck, Karl, I'm done. If he doesn't believe in "best" practices, it's his
loss. I did my best. ;-)

--
HTH,

Kevin Spencer
Microsoft MVP
..Net Developer
Neither a follower nor a lender be.

 

[tshad]

Heck, Karl, I'm done. If he doesn't believe in "best" practices, it's his
loss. I did my best. ;-)

Actually, I was not completely disagreeing with you. I was just saying that
it is not necessarily "the best" in all cases

 

[Guest]

I think your first mistake is using dreamweaver to develop .net apps, for it
has no intrinsic support for code behinds. Dreamweaver is good for html
editing and that'z about it.