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

[tshad]

"Juan T. Llibre" <no***********@ nowhere.com> wrote in message
news:eD******** ********@tk2msf tngp13.phx.gbl. ..

re:

What are we going to need to do to go to ASP.NET 2.0?
Is it just an add on or a whole different IIS?
It's just another version of the .NET Framework.

ASP.NET is an ISAPI program which runs against
a particular version of the .NET Framework.

You probably have both version 1.0
and 1.1 on your system now.

After you install .Net Framework 2.0,
you'll be able to run 1.1 apps and 2.0 apps side-by-side.

How does the .Net know which app you are running?

Is 2.0 going to be a different extension or is there a declaration like
DOCTYPE to tell how to run it?

Tom
re:

Do we know what the ~timeframe from MS is for 2.0?

Like I said, they promised Beta 2 for before the end of Q1.

They had promised it for last September, though.

I dropped out of a book authoring deal
because the dates kept slipping... ;-)

I'd be very surprised if Q4 2005 came and we still didn't
have a released version of both VS.NET 2005 and .NET 2.0


Juan T. Llibre
ASP.NET MVP
http://asp.net.do/foros/
Foros de ASP.NET en Español
=============== ======

"tshad" <ts**********@f tsolutions.com> wrote in message
news:%2******** ********@TK2MSF TNGP14.phx.gbl. ..

"Juan T. Llibre" <no***********@ nowhere.com> wrote in message
news:uP******** ******@tk2msftn gp13.phx.gbl...

As usual, there's a lot of speculation about Microsoft
product release dates, particularly with developer products.

The truth is...nobody knows when.

The best estimates about Beta 2 place it anywhere
from one month to two months from now, given that
it was promised by end of Q1.

Then, I'd guess that another 4-6 months before RTM,
and then allow 6-8 weeks for product distribution
( actually making the CD's & DVD's and getting them
out to retailers )

That would place product release at sometime
between 3rd and 4th quarters 2005.

If you can wait... do so.

You might also be able to get an upgrade coupon for 2005
when you purchase 2003. Check with whomever you're
planning to purchase it from.

An alternative is to download/install the betas as they are
released at http://lab.msdn.microsoft.com/express/

The Express products, particularly VWD for web development,
have very similar characteristics to Visual Studio, and you'll be
able to come up to speed with ASP.NET 2.0 before you
purchase Visual Studio, making a faster transition.

What are we going to need to do to go to ASP.NET 2.0?

We have our Web Servers on 2000 (IIS 5 - I believe) and 2003 (IIS6).

Is it just an add on or a whole different IIS?

Do we know what the ~timeframe from MS is for 2.0?

Thanks,

Tom

Juan T. Llibre
ASP.NET MVP
http://asp.net.do/foros/
Foros de ASP.NET en Español
=============== ======

"tshad" <ts**********@f tsolutions.com> wrote in message
news:OV******** *****@TK2MSFTNG P15.phx.gbl...
"Juan T. Llibre" <no***********@ nowhere.com> wrote in message
news:Oj******** ******@TK2MSFTN GP10.phx.gbl...
> re:
>> How soon is VS 2005 coming out?
>
> Beta 2 should happen sometime in the next month or so,
> and product release well before the end of the year,
> according to the pundits.
>
> re:
>> Is it going to be that much better that 2003?
>
> Oh, yes...

I am just curious because I just got the 60 day trial and don't want to
purchase it if the newer one is going to come out soon and have to pay
an exorbitant upgrade charge.

Tom

>
>
>
> Juan T. Llibre
> ASP.NET MVP
> http://asp.net.do/foros/
> Foros de ASP.NET en Español
> =============== ======
>
> "tshad" <ts**********@f tsolutions.com> wrote in message
> news:uI******** ********@TK2MSF TNGP12.phx.gbl. ..
>> "Juan T. Llibre" <no***********@ nowhere.com> wrote in message
>> news:eA******** ******@TK2MSFTN GP12.phx.gbl...
>>> re:
>>>> But, according to other posts here, VS also won't handle
>>>> code-inside pages - which it should !
>>>
>>> It will, as of VS.NET 2005.
>>
>> I am just getting ready to buy VS 2003. How soon is VS 2005 coming
>> out?
>>
>> Is it going to be that much better that 2003?
>>
>> Tom
>>>
>>> re:
>>>> Even though code behind is the preferred method, VS should be able
>>>> to handle both.
>>>
>>> It will, as of VS.NET 2005.
>>>
>>> re:
>>>> MS apparently won't let you do it your way (sound like a
>>>> commercial). One of the problems with them.
>>>
>>> No more...
>>>
>>> They've been listening to people like you. :-)
>>>
>>>
>>>
>>> Juan T. Llibre
>>> ASP.NET MVP
>>> http://asp.net.do/foros/
>>> Foros de ASP.NET en Español
>>> =============== ======
>>>
>>> "tshad" <ts**********@f tsolutions.com> wrote in message
>>> news:eq******** ******@TK2MSFTN GP09.phx.gbl...
>>>> "Larry David" <My************ ***@HealthyChoi ce.org> wrote in
>>>> message news:TM******** ************@gi ganews.com...
>>>>>
>>>>> "Brian" <Br***@discussi ons.microsoft.c om> wrote in message
>>>>> news:D8******** *************** ***********@mic rosoft.com...
>>>>>> 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.
>>>>>
>>>>> Hi,
>>>>>
>>>>> Sorry to jump in. My newsreader doesn't show the actual thread
>>>>> that led
>>>>> up to your response -- only the response itself. I'm not the
>>>>> original
>>>>> poster, just a lurker.
>>>>>
>>>>> You touched on using DreamWeaver for .NET projects. More and
>>>>> more people
>>>>> are doing this because the web design UI in VS.NET is horrible
>>>>> compared to
>>>>> DreamWeaver -- so horrible, in fact, that I too have had to resort
>>>>> to
>>>>> creating my pages in DreamWeaver and then copying them over to a
>>>>> Visual
>>>>> Studio environment where I write then write my C# code via
>>>>> code-behind. This
>>>>> is a real PITA. I'm hoping that the web designer UI in VS2005 will
>>>>> be much
>>>>> better so that I can ditch DreamWeaver all together.
>>>>
>>>> But, according to other posts here, VS also won't handle
>>>> code-inside pages - which it should !
>>>>
>>>> Even though code behind is the preferred method, VS should be able
>>>> to handle both.
>>>>
>>>> Actually, I use DW to do both. I have both pages open (the aspx
>>>> page and the code-behind page). When I am handling the objects or
>>>> the HTML, I just use switch to the aspx page and if I am working on
>>>> the Subs, I switch to the code behind page. DWMX2004 does a decent
>>>> job of using the asp.net objects. I have my issues with DW, but at
>>>> least I can code the way I want and not the way DW wants me too.
>>>>
>>>> MS apparently won't let you do it your way (sound like a
>>>> commercial). One of the problems with them.
>>>>
>>>> IMHO.
>>>>
>>>> Tom
>>>>>
>>>>> Larry
>>>
>>>
>>
>>
>
>

[Juan T. Llibre]

re:

How does the .Net know which app you are running?

Is 2.0 going to be a different extension or is there a declaration like
DOCTYPE to tell how to run it?
You register the .NET version which ASP.NET
will run against, by running " aspnet_regiis -i " .

Generally, that is done by the installation program.

A neat, free, ASP.NET Version Switcher was written by Denis Bauer.

You can find it at :
http://www.denisbauer.com/NETTools/A...nSwitcher.aspx

You can run any number of versions of ASP.NET,
side-by-side, in any number of virtual directories,
but you will need to run each version of ASP.NET
in a different Application Pool.

Juan T. Llibre
ASP.NET MVP
http://asp.net.do/foros/
Foros de ASP.NET en Español
=============== ======

"tshad" <ts**********@f tsolutions.com> wrote in message
news:ef******** ******@tk2msftn gp13.phx.gbl... "Juan T. Llibre" <no***********@ nowhere.com> wrote in message
news:eD******** ********@tk2msf tngp13.phx.gbl. ..

re:

What are we going to need to do to go to ASP.NET 2.0?
Is it just an add on or a whole different IIS?

It's just another version of the .NET Framework.

ASP.NET is an ISAPI program which runs against
a particular version of the .NET Framework.

You probably have both version 1.0
and 1.1 on your system now.

After you install .Net Framework 2.0,
you'll be able to run 1.1 apps and 2.0 apps side-by-side.

How does the .Net know which app you are running?

Is 2.0 going to be a different extension or is there a declaration like
DOCTYPE to tell how to run it?

Tom

re:

Do we know what the ~timeframe from MS is for 2.0?

Like I said, they promised Beta 2 for before the end of Q1.

They had promised it for last September, though.

I dropped out of a book authoring deal
because the dates kept slipping... ;-)

I'd be very surprised if Q4 2005 came and we still didn't
have a released version of both VS.NET 2005 and .NET 2.0


Juan T. Llibre
ASP.NET MVP
http://asp.net.do/foros/
Foros de ASP.NET en Español
=============== ======

"tshad" <ts**********@f tsolutions.com> wrote in message
news:%2******** ********@TK2MSF TNGP14.phx.gbl. ..

"Juan T. Llibre" <no***********@ nowhere.com> wrote in message
news:uP******** ******@tk2msftn gp13.phx.gbl...
As usual, there's a lot of speculation about Microsoft
product release dates, particularly with developer products.

The truth is...nobody knows when.

The best estimates about Beta 2 place it anywhere
from one month to two months from now, given that
it was promised by end of Q1.

Then, I'd guess that another 4-6 months before RTM,
and then allow 6-8 weeks for product distribution
( actually making the CD's & DVD's and getting them
out to retailers )

That would place product release at sometime
between 3rd and 4th quarters 2005.

If you can wait... do so.

You might also be able to get an upgrade coupon for 2005
when you purchase 2003. Check with whomever you're
planning to purchase it from.

An alternative is to download/install the betas as they are
released at http://lab.msdn.microsoft.com/express/

The Express products, particularly VWD for web development,
have very similar characteristics to Visual Studio, and you'll be
able to come up to speed with ASP.NET 2.0 before you
purchase Visual Studio, making a faster transition.

What are we going to need to do to go to ASP.NET 2.0?

We have our Web Servers on 2000 (IIS 5 - I believe) and 2003 (IIS6).

Is it just an add on or a whole different IIS?

Do we know what the ~timeframe from MS is for 2.0?

Thanks,

Tom

Juan T. Llibre
ASP.NET MVP
http://asp.net.do/foros/
Foros de ASP.NET en Español
=============== ======

"tshad" <ts**********@f tsolutions.com> wrote in message
news:OV******** *****@TK2MSFTNG P15.phx.gbl...
> "Juan T. Llibre" <no***********@ nowhere.com> wrote in message
> news:Oj******** ******@TK2MSFTN GP10.phx.gbl...
>> re:
>>> How soon is VS 2005 coming out?
>>
>> Beta 2 should happen sometime in the next month or so,
>> and product release well before the end of the year,
>> according to the pundits.
>>
>> re:
>>> Is it going to be that much better that 2003?
>>
>> Oh, yes...
>
> I am just curious because I just got the 60 day trial and don't want
> to purchase it if the newer one is going to come out soon and have to
> pay an exorbitant upgrade charge.
>
> Tom
>
>>
>>
>>
>> Juan T. Llibre
>> ASP.NET MVP
>> http://asp.net.do/foros/
>> Foros de ASP.NET en Español
>> =============== ======
>>
>> "tshad" <ts**********@f tsolutions.com> wrote in message
>> news:uI******** ********@TK2MSF TNGP12.phx.gbl. ..
>>> "Juan T. Llibre" <no***********@ nowhere.com> wrote in message
>>> news:eA******** ******@TK2MSFTN GP12.phx.gbl...
>>>> re:
>>>>> But, according to other posts here, VS also won't handle
>>>>> code-inside pages - which it should !
>>>>
>>>> It will, as of VS.NET 2005.
>>>
>>> I am just getting ready to buy VS 2003. How soon is VS 2005 coming
>>> out?
>>>
>>> Is it going to be that much better that 2003?
>>>
>>> Tom
>>>>
>>>> re:
>>>>> Even though code behind is the preferred method, VS should be able
>>>>> to handle both.
>>>>
>>>> It will, as of VS.NET 2005.
>>>>
>>>> re:
>>>>> MS apparently won't let you do it your way (sound like a
>>>>> commercial). One of the problems with them.
>>>>
>>>> No more...
>>>>
>>>> They've been listening to people like you. :-)
>>>>
>>>>
>>>>
>>>> Juan T. Llibre
>>>> ASP.NET MVP
>>>> http://asp.net.do/foros/
>>>> Foros de ASP.NET en Español
>>>> =============== ======
>>>>
>>>> "tshad" <ts**********@f tsolutions.com> wrote in message
>>>> news:eq******** ******@TK2MSFTN GP09.phx.gbl...
>>>>> "Larry David" <My************ ***@HealthyChoi ce.org> wrote in
>>>>> message news:TM******** ************@gi ganews.com...
>>>>>>
>>>>>> "Brian" <Br***@discussi ons.microsoft.c om> wrote in message
>>>>>> news:D8******** *************** ***********@mic rosoft.com...
>>>>>>> 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.
>>>>>>
>>>>>> Hi,
>>>>>>
>>>>>> Sorry to jump in. My newsreader doesn't show the actual thread
>>>>>> that led
>>>>>> up to your response -- only the response itself. I'm not the
>>>>>> original
>>>>>> poster, just a lurker.
>>>>>>
>>>>>> You touched on using DreamWeaver for .NET projects. More and
>>>>>> more people
>>>>>> are doing this because the web design UI in VS.NET is horrible
>>>>>> compared to
>>>>>> DreamWeaver -- so horrible, in fact, that I too have had to
>>>>>> resort to
>>>>>> creating my pages in DreamWeaver and then copying them over to a
>>>>>> Visual
>>>>>> Studio environment where I write then write my C# code via
>>>>>> code-behind. This
>>>>>> is a real PITA. I'm hoping that the web designer UI in VS2005
>>>>>> will be much
>>>>>> better so that I can ditch DreamWeaver all together.
>>>>>
>>>>> But, according to other posts here, VS also won't handle
>>>>> code-inside pages - which it should !
>>>>>
>>>>> Even though code behind is the preferred method, VS should be able
>>>>> to handle both.
>>>>>
>>>>> Actually, I use DW to do both. I have both pages open (the aspx
>>>>> page and the code-behind page). When I am handling the objects or
>>>>> the HTML, I just use switch to the aspx page and if I am working
>>>>> on the Subs, I switch to the code behind page. DWMX2004 does a
>>>>> decent job of using the asp.net objects. I have my issues with DW,
>>>>> but at least I can code the way I want and not the way DW wants me
>>>>> too.
>>>>>
>>>>> MS apparently won't let you do it your way (sound like a
>>>>> commercial). One of the problems with them.
>>>>>
>>>>> IMHO.
>>>>>
>>>>> Tom
>>>>>>
>>>>>> Larry
>>>>
>>>>
>>>
>>>
>>
>>
>
>

[Alan Silver]

>The Express products, particularly VWD for web development, have very

similar characteristics to Visual Studio, and you'll be able to come up
to speed with ASP.NET 2.0 before you purchase Visual Studio, making a
faster transition.

"up to speed" is a lovely expression, especially considering the snail's
pace response of VWD. I downloaded that beta, and was quite impressed
with the product, but gave up with it very quickly due to it being
unbelievably slow to use. When viewing the HTML, it can take 10 seconds
to notice when I click my mouse somewhere else in the code. Typing lags
noticeably behind too.

I know I don't have the fastest machine going (PII 500MHz, 256Mb RAM),
but Visual Studio 6 (pre-.NET) runs like a dream, VWD crawls like an
asthmatic ant carrying a load of heavy shopping!!

--
Alan Silver
(anything added below this line is nothing to do with me)

[Alan Silver]

>> if you are the only

one working on the code, it seem a little overkill.
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.

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.

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.

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

That's a good thing.

Why? It just makes extra work.

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.

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 ;-)

--
Alan Silver
(anything added below this line is nothing to do with me)

[Kevin Spencer]

It's really the wrong question. It's not a matter of "Code-Behind" versus
"Code-Beside." It's a matter of code organization in general. As ASP.Net app
is not a collection of unrelated Page classes. It is an application. It is
also object-oriented.

If you ever plan for extensibility, code-maintenance, and optimization,
separating various operations into classes is essential. If you're just
working on a simple and small app, it is less important. The larger and more
complex your apps are, the more you will benefit from the use of good
object-oriented principles, which includes abstraction, ploymorphism, and
encapsulation, as well as inheritance.

The Page's Code-Behind model is simply an extension of those principles.
People who don't like it generally are either working on very small
projects, and have never worked on large ones, or simply don't want to work
to learn OOP principles and application of them.

OOP is a learning curve. But it came about as a necessary extension of
procedural programming, and in response to the limitations of procedural
programming, just as Assembler was developed to improve productivity over
using Machine language. And if one is unwilling to adapt, think of the
consequences when the next generation of programming architecture comes out:
AOP (Aspect-Oriented Programming). AOP is coming soon!

Hang ten or die!

--
HTH,

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

"Alan Silver" <al*********@no spam.thanx> wrote in message
news:6n******** ******@nospamth ankyou.spam...

if you are the only
one working on the code, it seem a little overkill.

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.

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.

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.

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

That's a good thing.

Why? It just makes extra work.

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.

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
architectur e, 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 ;-)

--
Alan Silver
(anything added below this line is nothing to do with me)

[Alan Silver]

>If you ever plan for extensibility, code-maintenance, and optimization,

separating various operations into classes is essential. If you're just
working on a simple and small app, it is less important. The larger and
more complex your apps are, the more you will benefit from the use of
good object-oriented principles, which includes abstraction,
ploymorphism , and encapsulation, as well as inheritance.

This is precisely the point I was making. Believe it or not, many of us
make our living on small applications that are highly unlikely to become
enterprise-scale applications. I often work on small apps and find that
many "best practice" techniques are overkill. Sure, when working on big
apps they are important, but sometimes they can just get in the way of
getting the job done.

As I said before, you have to judge each case on its own merits. There
are times when you will want one method, and times when you will want
another. Blanket statements claiming that code-behind (or anything else
for that matter) is the only correct way to do it are misleading and
incorrect.

Thanks for your reply.

--
Alan Silver
(anything added below this line is nothing to do with me)

[tshad]

"Alan Silver" <al*********@no spam.thanx> wrote in message
news:KE******** ******@nospamth ankyou.spam...

If you ever plan for extensibility, code-maintenance, and optimization,
separating various operations into classes is essential. If you're just
working on a simple and small app, it is less important. The larger and
more complex your apps are, the more you will benefit from the use of
good object-oriented principles, which includes abstraction,
ploymorphism , and encapsulation, as well as inheritance.

This is precisely the point I was making. Believe it or not, many of us
make our living on small applications that are highly unlikely to become
enterprise-scale applications. I often work on small apps and find that
many "best practice" techniques are overkill. Sure, when working on big
apps they are important, but sometimes they can just get in the way of
getting the job done.

As I said before, you have to judge each case on its own merits. There are
times when you will want one method, and times when you will want another.
Blanket statements claiming that code-behind (or anything else for that
matter) is the only correct way to do it are misleading and incorrect.

These were the points I was trying to make and am glad to see someone else
thinking the same way I do.

I also feel that you need to look at the situations. Rarely is there only
*one* way to do anything. I just wanted to see the pluses and minus of both
styles.

Kevin really made the point.

"People who don't like it generally are either working on very small
projects, and have never worked on large ones, or simply don't want to work
to learn OOP principles and application of them".

I think he slightly misses the point, as you were mentioning, that it is
more work on a small project. It is not necessarily that they don't like
it, it is just less work. If it is a larger project, it may be better in
most cases to write code-behind. But the biggest advantage, that I have
been able to gleen from this, is that multiple people can work on the same
application at the same time. But if you are the only person, this
advantage is lost.

Just because you *can* do something, doesn't mean you *should* do something.

OOP is a good thing. But it isn't the only thing. I do build my own
classes, but I am not going to build a whole class for 2 lines of code.

I can see the advantages of both styles. But you can't make a choice until
you understand both styles.

Tom

[Kevin Spencer]

> I think he slightly misses the point, as you were mentioning, that it is

more work on a small project. It is not necessarily that they don't like
it, it is just less work. If it is a larger project, it may be better in
most cases to write code-behind. But the biggest advantage, that I have
been able to gleen from this, is that multiple people can work on the same
application at the same time. But if you are the only person, this
advantage is lost.
I didn't miss any point. Do you know the average length of time it takes to
develop a habit? 6 weeks. So, assuming that you've been working with ASP.Net
for more than 6 weeks, you've already developed some habits. Now, let's say
you graduate from working on tiny applications to something of some size and
scope. It will take you another 6 weeks to teach yourself to do it right.

I've been programming for about 10 years now. This is not theory; it is my
experience. In my experience, more work in the short run always leads to
less work in the long run. Today is gone tomorrow. But tomorrow is always
just around the bend.

My philosphy: If, when you are beginning, you develop and practice best
practices, you will not be beginning for long.

Programmers are a dime a dozen. Good programmers are rare. If you want to
make money, you have to distinguish yourself. Start early, and you'll never
be without a good-paying job.

--
HTH,

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

"tshad" <ts**********@f tsolutions.com> wrote in message
news:%2******** *******@TK2MSFT NGP15.phx.gbl.. . "Alan Silver" <al*********@no spam.thanx> wrote in message
news:KE******** ******@nospamth ankyou.spam...

>If you ever plan for extensibility, code-maintenance, and optimization,
>separating various operations into classes is essential. If you're just
>working on a simple and small app, it is less important. The larger and
>more complex your apps are, the more you will benefit from the use of
>good object-oriented principles, which includes abstraction,
>ploymorphism , and encapsulation, as well as inheritance.

This is precisely the point I was making. Believe it or not, many of us
make our living on small applications that are highly unlikely to become
enterprise-scale applications. I often work on small apps and find that
many "best practice" techniques are overkill. Sure, when working on big
apps they are important, but sometimes they can just get in the way of
getting the job done.

As I said before, you have to judge each case on its own merits. There
are times when you will want one method, and times when you will want
another. Blanket statements claiming that code-behind (or anything else
for that matter) is the only correct way to do it are misleading and
incorrect.

These were the points I was trying to make and am glad to see someone else
thinking the same way I do.

I also feel that you need to look at the situations. Rarely is there only
*one* way to do anything. I just wanted to see the pluses and minus of
both styles.

Kevin really made the point.

"People who don't like it generally are either working on very small
projects, and have never worked on large ones, or simply don't want to
work
to learn OOP principles and application of them".

I think he slightly misses the point, as you were mentioning, that it is
more work on a small project. It is not necessarily that they don't like
it, it is just less work. If it is a larger project, it may be better in
most cases to write code-behind. But the biggest advantage, that I have
been able to gleen from this, is that multiple people can work on the same
application at the same time. But if you are the only person, this
advantage is lost.

Just because you *can* do something, doesn't mean you *should* do
something.

OOP is a good thing. But it isn't the only thing. I do build my own
classes, but I am not going to build a whole class for 2 lines of code.

I can see the advantages of both styles. But you can't make a choice
until you understand both styles.

Tom

[Alan Silver]

>Just because you *can* do something, doesn't mean you *should* do

something.

Perhaps the wisest words said today.

Perhaps not, but pretty sharp either way!!

--
Alan Silver
(anything added below this line is nothing to do with me)

[Kevin Spencer]

"Alan Silver" <al*********@no spam.thanx> wrote in message
news:JA******** ******@nospamth ankyou.spam...

Just because you *can* do something, doesn't mean you *should* do
something.

Perhaps the wisest words said today.

Perhaps not, but pretty sharp either way!!

--
Alan Silver
(anything added below this line is nothing to do with me)

This has nothing to do with Alan Silver. Oh darn. It has his name it it.

;-)

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