Code Behind vs not

[Alan Silver]

This discussion seems to have focused mostly on complexity and coding styles,

and missed one of the key benefits of code behind.

<snip>

Given the insignificant compilation time on a modern machine, and given
that most production servers are rarely rebooted, this advantage is
minimal at the best. Once the site is running, you often only update one
or two pages at a time, and you can always load those yourself to make
sure no-one else has to wait whilst it recompiles. let's face it, anyone
who uploads new files to a production server and *doesn't* check them
out immediately is asking for trouble, so there's little benefit in your
point.

The only advantage I have seen for inline coding is

<snip>

Then may I suggest you read this thread again. Many benefits have been
suggested. As has been commented several times, there's no *best*
approach, each situation requires judging on its own merits. Code-beside
has many advantages and is the best approach in many situations. Not
all, but enough to render it a genuine and viable approach to be
considered.

Every thing I have read, and conversations I have had with MSFT contacts
involved in developing ASP.NET suggest that the only reason the inline coding
style is available at all is to ease the transition for the thousands of ASP
developers who never really learned how to program.

Depends who you ask ;-) My opinion of the opinion of MS programmers is
severely tainted by some of the stories I've heard. My brother is one
such Ms programmer and from what he tells me, what goes on inside MS and
what they want us to do are often significantly different.

Ta ra

 

[Aquila Deus]

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.

You wouldn't need code behind only if:
1.It's simple enough to be written in PHP or ASP. But I can't really
find any example that PHP/ASP can do better than ASP.NET.
2.You are going to throw the web-project into trash can once it's
finished.
3.You are blind.

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.

Why do you need Dreamweaver?? With ASP.NET you can easily write
templated user controls and custom controls, which are much more
powerful and reusable than traditional templates!

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.

The project would have already failed if you part it by pages.

 

[tshad]

Hello all,

The arguement for Code Behind is simple.

No.

"An" argument for Code Behind - not "The" argument.

If you need your page to render in English and you need your page to also
render in Japanese, Hebrew, and others, then you need some mechanism to
isolate the actual program code and business logic from the presentation
of
the pages.

Definately, a good reason to do this.

And how many of us are worried about this issue. Not me. So therefore, not
a good reason for me.

With ASP and PHP, you traditionally had to do a lot of work in order to
achieve this separation, you had to implement templating systems, etc.
And
most of the common techniques -- replacement strings, etc. -- made user
interfaces look kludgey and unrefined on many foreign systems.

With code behind, you can have a separate presentation file for each
language that you support. That presentation file can be edited by
standard
web tools by a web design specialist who may have no programming knowledge
at
all, who may understand only (X)HTML. The fields and prompts, button
layout,
etc. can all be set up however it is desired for the target language.
However they need for it to be set up.

A typical "real" ASP.NET application also will have classes that aren't
part
of the user interface.

Here you are talking about setting up separate classes that aren't
necessarily part of the page. This can be done without Code-Behind.

In the real world, giving your web server that is
exposed to the public internet direct access to your SQL Server is a
serious
security risk, one that can be exploited to gain access to information you
may not want attackers to have access to (such as credit card numbers,
e-mail
addresses, etc.)

I don't see how this is an argument for Code-Behind. Definately a
discussion of security, SQL injection (which would a problem in either
case).

Also, if your application is complicated enough to benefit from
inheretence,
then you also will want to be using code behind. Inheritence of code
contained in .aspx files is painful at absolute best.
Agreed.


And of course, you might want to use private key pairs and strong names to
validate your web application hasn't been tampered with. You do this by
putting the business logic in the GAC, and strongly naming your code. The
code in the GAC is much harder to attack, so if it knows the strong names
of
authorized callers, then an attacker must have the keys to modify the
application code.

But because aspx files generate their code automatically, every time they
are run, you can't easily strongly name them. And so you must use code
behind if it is important to have mutual validation. The trick to
accomplishing this is inheritence.

Definately all good reasons for code-behind.

Tom

 

[tshad]

Let's rephrase that slightly and say *an* argument, not *the* argument. I
agree that in the case when you want to do this, code-behind gives a great
advantage, but for those of us who have never had this need, nor envisage
it as a likely possibility, it's not a very compelling argument.



As mentioned several times in this thread, that's an issue of taking
certain parts of code into separate modules and is little to do with
code-behind vs code-beside. You can separate out modules either way.


OK, a valid point, but again, not something that's relevant to most people
most of the time.


Ditto

Don't get me wrong, I'm not arguing in principle, there are many times
when code-behind has strong advantages, but equally there are many times
when code-beside has the advantages. I just get fed up of the blanket
statements to the effect that code-behind is better and that's the end of
the discussion. I'm not saying you do this, I'm saying it happens a lot
and seems to be an inaccurate approach to the issue.

Here - here !!

As with many things, there are good and bad about most things and rarely is
there only one way. The best way to distinquish between options is to see
all ( or as many as possible) and make an informed choice. I always have a
problem with someone who says he has all the answers and that his way is the
only way. You can't make a choice if you don't know the options. You will
rarely get options from from someone who only knows one way of doing things.

I actually like both approaches.

Tom

 

[Alan Silver]

You wouldn't need code behind only if:

1.It's simple enough to be written in PHP or ASP. But I can't really
find any example that PHP/ASP can do better than ASP.NET.

Who says you *need* code-behind for anything other than stupidly simple
sites? I mean, I know *you* said it, but without any justification or
further comment, we can only consider this as yet another uninformed
blind opinion.

Read the rest of this thread and you will see people saying over and
over again that the important point is to consider all options and use
whatever method is most appropriate for the situation. This may be
code-behind, or it may not. There is no blanket right or wrong like you
imply.

2.You are going to throw the web-project into trash can once it's
finished.

Are we supposed to consider this as a serious comment, or is it an
attempt at humour? Either way, it adds nothing to the discussion.

3.You are blind.
Ditto.

Why do you need Dreamweaver?? With ASP.NET you can easily write
templated user controls and custom controls, which are much more
powerful and reusable than traditional templates!

Maybe you've never heard of Dreamweaver, maybe you don't understand what
"graphic design" means. I have no idea what sort of site you turn out,
but if you think you can create eye-catching visuals in VS, then you are
obviously a programmer not a designer!!

The project would have already failed if you part it by pages.

Another blanket statement without support. I suppose you consider all
sites that have their logic in the pages to be failures? Again, I don't
know what kind of sites you produce, but my experience is that the vast
majority of pages on sites are largely self-contained. If you think
differently, please provide some reasoned argument to support your
point.

 

[tshad]

Who says you *need* code-behind for anything other than stupidly simple
sites? I mean, I know *you* said it, but without any justification or
further comment, we can only consider this as yet another uninformed blind
opinion.

Read the rest of this thread and you will see people saying over and over
again that the important point is to consider all options and use whatever
method is most appropriate for the situation. This may be code-behind, or
it may not. There is no blanket right or wrong like you imply.


Are we supposed to consider this as a serious comment, or is it an attempt
at humour? Either way, it adds nothing to the discussion.



Maybe you've never heard of Dreamweaver, maybe you don't understand what
"graphic design" means. I have no idea what sort of site you turn out, but
if you think you can create eye-catching visuals in VS, then you are
obviously a programmer not a designer!!



Another blanket statement without support. I suppose you consider all
sites that have their logic in the pages to be failures? Again, I don't
know what kind of sites you produce, but my experience is that the vast
majority of pages on sites are largely self-contained. If you think
differently, please provide some reasoned argument to support your point.

I suppose that all the straight asp pages are all failures and nothing
substantial has ever been written until asp.net and code-behind hit the
scene

Tom

 

[Kevin Spencer]

Your turn, Alan.

--
;-),

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

Who says you *need* code-behind for anything other than stupidly simple
sites? I mean, I know *you* said it, but without any justification or
further comment, we can only consider this as yet another uninformed
blind opinion.

Read the rest of this thread and you will see people saying over and over
again that the important point is to consider all options and use
whatever method is most appropriate for the situation. This may be
code-behind, or it may not. There is no blanket right or wrong like you
imply.


Are we supposed to consider this as a serious comment, or is it an
attempt at humour? Either way, it adds nothing to the discussion.



Maybe you've never heard of Dreamweaver, maybe you don't understand what
"graphic design" means. I have no idea what sort of site you turn out,
but if you think you can create eye-catching visuals in VS, then you are
obviously a programmer not a designer!!



Another blanket statement without support. I suppose you consider all
sites that have their logic in the pages to be failures? Again, I don't
know what kind of sites you produce, but my experience is that the vast
majority of pages on sites are largely self-contained. If you think
differently, please provide some reasoned argument to support your point.

I suppose that all the straight asp pages are all failures and nothing
substantial has ever been written until asp.net and code-behind hit the
scene

Tom

 

[Aquila Deus]

Who says you *need* code-behind for anything other than stupidly simple
sites? I mean, I know *you* said it, but without any justification or

further comment, we can only consider this as yet another uninformed
blind opinion.

Read the rest of this thread and you will see people saying over and
over again that the important point is to consider all options and use
whatever method is most appropriate for the situation. This may be
code-behind, or it may not. There is no blanket right or wrong like you
imply.

The only appropriate method is put UI in aspx and logic in code-behind
file. Thus you don't need to use code-behind only if your web-site does
nothing but display static text.

Are we supposed to consider this as a serious comment, or is it an
attempt at humour? Either way, it adds nothing to the discussion.

Coding in aspx causes the web-site unmaintainable when it becomes
bigger and bigger.

Maybe you've never heard of Dreamweaver, maybe you don't understand what
"graphic design" means. I have no idea what sort of site you turn out,
but if you think you can create eye-catching visuals in VS, then you are
obviously a programmer not a designer!!

But why don't designers just draw on papers and code in html/css
directly?

I have a site at: http://aqdhome.sourceforge.net/index.xml

As you can see it's not beautiful, but how can dreamwever do it? Can it
create text shadow and translucent layer? Or manage my css files to
make them easy to maintain? Does it even support XSLT?

page


Another blanket statement without support. I suppose you consider all

sites that have their logic in the pages to be failures? Again, I don't
know what kind of sites you produce, but my experience is that the vast
majority of pages on sites are largely self-contained. If you think
differently, please provide some reasoned argument to support your
point.

Do you think most of web-sites are good enough for you to follow their
design?

 

[Alan Silver]

I suppose that all the straight asp pages are all failures and nothing

substantial has ever been written until asp.net and code-behind hit the
scene

Apparently so. Please don' tell my clients though. Some of them are
actually quite pleased with the sites I've produced. If they find out
that ASP was a major failure and not capable of producing anything
worthwhile, I'll be in big trouble!!

 

[Alan Silver]

Your turn, Alan.

See my incisive and witty reply ;-)

 

[Alan Silver]

I'd just like to point out before adding any comments to the following
that I hereby give up answering the "arguments" offered by Aquila. I
have asked for support for the blanket statements and have been given
more blanket statements. It's not worth pursuing the argument. If anyone
reads this thread at a later date, I would like to be on record (along
with lots of other people here I suspect) as saying that I consider the
statements made by Aquila in favour of code-behind to be poor and
ill-considered. That's nothing personal against him/her, nor a comment
against code-behind. Other people have offered very sensible reasons for
using it. This part of the thread though contains none of that, just one
person's blind opinion with no attempt at support.

Right, disclaimer out the way, here are my final words on Aquila's
comments ...

The only appropriate method is put UI in aspx and logic in code-behind
file. Thus you don't need to use code-behind only if your web-site does
nothing but display static text.

Yet again I would ask you to support this ludicrous blanket statement.
Evidently you can't, or you would have done by now.

There are many methods, each appropriate to its own situation.
Code-behind is one, but is not the only one. Any statement that claims
that any one method is the "only appropriate" one is incorrect.

Coding in aspx causes the web-site unmaintainable when it becomes
bigger and bigger.

Of course, I'm sure all of the web masters of large sites would
completely agree with you, that's why all of the large sites on the
Internet are unusable and cannot be maintained.

Another stupid blanket statement with no support, nor any connection to
reality. A site is as good as the programmer(s) who wrote it. If it was
written well, it will be maintainable, even if it grows large. Obviously
ASP.NET has advantages over Classic for this, but that does not mean
that Classic was unmaintainable.

Your "arguments" are getting more and more ridiculous the more this
thread continues.

But why don't designers just draw on papers and code in html/css
directly?

Why should they? We have perfectly good graphics design tools at our
fingertips, why not use them?

I have a site at: http://aqdhome.sourceforge.net/index.xml

As you can see it's not beautiful, but how can dreamwever do it? Can it
create text shadow and translucent layer? Or manage my css files to
make them easy to maintain? Does it even support XSLT?

I can't answer these questions as I've never used DW, but I strongly
suspect that it can do all of these and a lot more. From what I
understand, it's an extremely powerful design package.

In case you haven't realised, shadows, translucent layers, css and so on
are all graphical elements. These are the sort of thing for which DW and
it's colleagues were designed. If you are even asking the question, it
shows you have no idea what DW is, nor what it is used for.

Do you think most of web-sites are good enough for you to follow their
design?

I was referring to my own sites, and yes I do think their designs are
good enough for me to follow.

My comment was on the general structure and nature of web sites. IME
most sites have pages that do a particular job. Rarely do I see a site
(or a requirement) to have pages that are so closely interwoven that I
would even consider placing their page-specific code in a common module.
If two pages were that closely woven, I would question whether the two
should actually be one page in the first place.

That's not so say you never find these situations, but IME they are the
exception, not the rule.

OK, that's the end of my comments on Aquila's unsupported opinions.
He/she can argue back all day for all I care, I have neither the time
nor the inclination to argue with someone whose idea of a debate is to
repeat the same unsupported blanket statements in response to replies.
This is not a flame, nor anything personal, I just find the opinions
stated in this thread to be not worthy of further comment.

Ta ra

 

[Aquila Deus]

I'd just like to point out before adding any comments to the following
that I hereby give up answering the "arguments" offered by Aquila. I
have asked for support for the blanket statements and have been given

more blanket statements. It's not worth pursuing the argument. If anyone
reads this thread at a later date, I would like to be on record (along
with lots of other people here I suspect) as saying that I consider the
statements made by Aquila in favour of code-behind to be poor and
ill-considered. That's nothing personal against him/her, nor a comment
against code-behind. Other people have offered very sensible reasons for
using it. This part of the thread though contains none of that, just one
person's blind opinion with no attempt at support.

Right, disclaimer out the way, here are my final words on Aquila's
comments ...



Yet again I would ask you to support this ludicrous blanket statement.
Evidently you can't, or you would have done by now.

There are many methods, each appropriate to its own situation.
Code-behind is one, but is not the only one. Any statement that claims
that any one method is the "only appropriate" one is incorrect.

Then please tell me in what kind of situation putting busniess logic
code in aspx is better than putting in code-behind? "Hello World"?

Of course, I'm sure all of the web masters of large sites would
completely agree with you, that's why all of the large sites on the
Internet are unusable and cannot be maintained.

Another stupid blanket statement with no support, nor any connection to
reality. A site is as good as the programmer(s) who wrote it. If it was
written well, it will be maintainable, even if it grows large. Obviously
ASP.NET has advantages over Classic for this, but that does not mean
that Classic was unmaintainable.

But Classic is indeed less maintainable. So why use it at all?

Your "arguments" are getting more and more ridiculous the more this
thread continues.

And how about you?

Why should they? We have perfectly good graphics design tools at our
fingertips, why not use them?

Only if the tools are really good.

I can't answer these questions as I've never used DW, but I strongly
suspect that it can do all of these and a lot more.

I know it can do a lot, but is it more convenient than hand-writing in
my case? (I would say yes only if it can handle layers and translucent
as natural as photoshop)

From what I
understand, it's an extremely powerful design package.

Heh, how do you understand this?

In case you haven't realised, shadows, translucent layers, css and so on
are all graphical elements. These are the sort of thing for which DW and
it's colleagues were designed. If you are even asking the question, it
shows you have no idea what DW is, nor what it is used for.

I don't care wtf it is. My concern is how it can help me?

I was referring to my own sites, and yes I do think their designs are

good enough for me to follow.

My comment was on the general structure and nature of web sites. IME
most sites have pages that do a particular job. Rarely do I see a site
(or a requirement) to have pages that are so closely interwoven that I
would even consider placing their page-specific code in a common module.
If two pages were that closely woven, I would question whether the two
should actually be one page in the first place.

Then the page will become bigger and bigger.

That's not so say you never find these situations, but IME they are the
exception, not the rule.

A good design should be able to deal with the most extreme situations.

OK, that's the end of my comments on Aquila's unsupported opinions.
He/she can argue back all day for all I care, I have neither the time

nor the inclination to argue with someone whose idea of a debate is to
repeat the same unsupported blanket statements in response to replies.
This is not a flame, nor anything personal, I just find the opinions
stated in this thread to be not worthy of further comment.

heh

 

[Aquila Deus]

point.

I suppose that all the straight asp pages are all failures and

nothing

and php, too.

substantial has ever been written until asp.net and code-behind hit the
scene

Agreed!

 

[Kevin Spencer]

Your "arguments" are getting more and more ridiculous the more this

And how about you?

Meow! R-r-r-o-w-w-r-r!

--
;-),

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

 

[Guest]

Tom:

It is not wise to code for a tool. If you decide to keep all of your code in
the ASPX files, that is fine, but do not use "I use Dreamweaver and it is
harder" as your primary motivation. As you will see, keeping code in one file
makes more sense as you move into the 2.0 Framework, so it is not necessarily
a bad decision. Just make sure you are making the decision for the right
reason.

Here is an example of an ASPX with no CodeBehind:
<%@ Page language="c#" AutoEventWireup="false" %>
<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.0 Transitional//EN" >
<HTML>
<HEAD>
<title>No code behind</title>
<script language="C#" runat="server">
private void btnFill_Click(object sender, System.EventArgs e)
{
txtFill.Text = btnFill.Text;
}
</script>
</HEAD>
<body>
<form id="Form1" method="post" runat="server">
<h1>No code behind page</h1>
<P><asp:Button id=btnFill runat="server"
Text="Click me to fill text box"
OnClick="btnFill_Click"></asp:Button>
<asp:TextBox id=txtFill runat="server" /></P>
</form>
</body>
</HTML>

When you divorce ASPX, you have a page that is not inheriting from a base
class you create, but is handled as inheriting directly from the Page class.
The issue here is two-fold:

1. You are moving from an explicit model to an implicit model. What this
ultimately means is you have less control over your code. Fortunately,
Microsoft has lessened the impact in this case, but you still have some items
potentially hidden from you when you moved to implied code.

2. You are creating a web site that must be maintained by someone who
understands code. When you have tags and code together, you cannot simply
send the files to a graphic artist and let him use any tool to design the
look and feel, as some tools will get rid of code blocks they do not
understand. This is not as big of a problem today, as most tools are designed
to avoid things they do not understand.

A bit about internals: Underneath the hood, your tagged page (the .aspx
part) inherits from your code behind file (the .aspx.cs or .aspx.vb, etc.).
You can remove both the CodeBehind= and the Inherits= from the @ directive
and then place your server side code in your files. The negative here is you
cannot prebuild your IL, so you take a slightly higher hit when you first
instantiate your file, as you are both IL compiling and JIT compiling. In the
2.0 Framework, this is less destructive, as there is a .axd file that can
compile everything in your site. If you have a "code walker" that compiles
pages (wise even with the CodeBehind implementation).

The main benefit, for a coder, with placing code in a separate file is it
gives you the ability to focus solely on the code. In Visual Studio 2005, the
code gets separated even when located in the ASPX file, but this is due to a
parsing trick rather than true separation. In VS.NET 200x, you end up with
tags and code mixed, as you do with Dreamweaver.

I would not do it, personally, but I have seen too many people make mistakes
in the ASP world that were migrated to the ASP.NET world. Ouch!!!

---

Gregory A. Beamer
MVP; MCP: +I, SE, SD, DBA

***************************
Think Outside the Box!
***************************

 

[Guest]

There are discernable benefits, but they are largely below the surface. From
a coding standpoint, either model will work. And, with 2.0, Microsoft is
making it easier for the "embedding" coder to work. The 2.0 implementation
works better, as partial classes make a better OO model (a discussion for
another thread).

When you embed code in your page, you are moving from an explicit model to
an implicit model. If you have an ASP background, here is a prime example:

In ASP (and VB COM), you had the ability, via ADO, to explicitly set a
connection, a command and then fill a recordset. You also had a shortcut
method that allowed you to call a SQL command directly from a method on a
recordset, passing in a connection string. The first method was explicit, and
allowed you to program against all of the objects (connection, command and
recordset). The second method was implicit, as the connection and command
were hidden. No problem, however, as your recordset was filling fine. Then,
someone changes the SQL from an ad hoc type of query (built in the page) to a
stored procedure. Without access to the command object to change the command
type, the whole enchilada blows.

I know of no danger in going implicit in the ASP.NET page model, but I have
had no reason to experiment, as I am fully satisfied with CodeBehind. Perhaps
someone else has played with the model.

Overall, deleting CodeBehind from the model leads you to a model where you
are working with a kludged OO methodology. If you feel it is worth it to work
with Dreamweaver, that is your decision. But, a future version of Dreamweaver
may better support CodeBehind, so you should realize you are coding simply to
make things easier in the present.

---

Gregory A. Beamer
MVP; MCP: +I, SE, SD, DBA

***************************
Think Outside the Box!
***************************

Dim rs As Recordset
rs.F

 

[Guest]

I would disagree with that statement, Brian. Dreamweaver has a lot of bang
for the buck. While it is focused on the design more than the code, and has
no support for code behind (intricately linking the two files), Dreamweaver
is a great tool for those who do not need a full Visual Studio experience. I
prefer it over FrontPage for .NET development (although the newest version of
FP is much better).


---

Gregory A. Beamer
MVP; MCP: +I, SE, SD, DBA

***************************
Think Outside the Box!
***************************

 

[Guest]

To see that VS handles non-codeBehind pages, you can copy this page into your
web in Visual Studio and see that you can still drag and drop new controls.
You will have to declaratively link code events and create the stubs
yourself, but you have to do the same in tools like Dreamweaver.

<%@ Page language="c#" AutoEventWireup="false" %>
<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.0 Transitional//EN" >
<HTML>
<HEAD>
<title>No code behind</title>
<script language="C#" runat="server">
private void btnFill_Click(object sender, System.EventArgs e)
{
txtFill.Text = btnFill.Text;
}
</script>
</HEAD>
<body>
<form id="Form1" method="post" runat="server">
<h1>No code behind page</h1>
<P><asp:Button id=btnFill runat="server"
Text="Click me to fill text box"
OnClick="btnFill_Click"></asp:Button>
<asp:TextBox id=txtFill runat="server" /></P>
</form>
</body>
</HTML>

NOTE: Visual Studio 2005 will link events with embedded code, so it can go
either way.

---

Gregory A. Beamer
MVP; MCP: +I, SE, SD, DBA

***************************
Think Outside the Box!
***************************

 

[Guest]

Alan:

There is nothing wrong with making a decision to go to a single file over
two files. The main issue I have with it is the reasoning. "My tool does not
support" is not, IMO, a good reason to adopt an implicit model over an
explicit model.

In Dreamweaver, you are generally working design, or your are working code.
There are cases where you are doing both, but bouncing back and forth is not
the norm, except during a debug cycle (ie, why doesn't the control event fire
properly). As the overlap is not the norm, you generally do not have two
files open at the same time. This may not be true for you, but I am most
often embedded in either design (how does it look) or functionality (the
code), as they are two separate entities.

Bearing the above in mind, the only "pain" with Dreamweaver is you have to
open a different file to work with code. As you should be focused on code
when you are coding, this is not a major pain ... unless you are mixing
metaphors and having design drive code or code drive design. If you are
having one drive the other, you are creating inferior applications in most
instances.

If you find you are constantly shifting back and forth from tags to code,
you may want to examine your development methodology, as you are likely
having the look influence functionality, or visa versa.


---

Gregory A. Beamer
MVP; MCP: +I, SE, SD, DBA

***************************
Think Outside the Box!
***************************

 

[Guest]

There are a few rules I have learned in my years in software:

1. Little applications eventually become large applications. This is not
true with all apps, but small companies often become large companies over
time, and many legacy applications live on far longer than they should.

2. Too many applications are under-engineered. While over-engineering is a
mistake, under-engineering leads to memory leaks, security leaks, etc.
Microsoft, today, is suffering for under-engineering many of the products,
leading to a huge number of patches today.

3. Bad design eventually catches up to you.

I am not saying that making a decision for a single page is bad, but it
should be a concious decision made after examining the issue completely. If
you are making this decision to fit a tool, it is, IMO, an unwise decision.

Fortunately, Microosoft is going to compensate for those who like a single
file in the next version of Visual Studio, so the decision is less "defined".


---

Gregory A. Beamer
MVP; MCP: +I, SE, SD, DBA

***************************
Think Outside the Box!
***************************