Re: TRICK: methods in ASPX pages with <%%> code blocks





who has it?

why not me?

big chunks of what is in asp.net today

i wrote myself in vb6 for asp about 8 years ago

code blocks aren't evil, they are the most intelligent
way of handling html literals in presentation logic

whether pre compiled or jit compiled, in methods, classes, controls
or anything you like










Kevin Spencer wrote:
> > Bottom line, if you like coding on your page, great. If you like
> > code-behind, great.
> > Remember, however, if you're on a development team, pick one or the other.
> > Settle it with a toss of a coin or arm-wrestle. Then stick to it. I've
> > been
> > involved in projects where there's been a mixture and it can be confusing
> > going from one to the other and from an architecture standpoint, it's not
> > good practice.
>
> The real bottom line is, if you are serious about making a living as a
> developer, adopt best practices. They are called "best practices" because
> they improve the performance of the developer, and the performance,
> scalability, and maintainability of the software that the developer creates.
> Best practices are arrived at by experienced developers who have observed
> the problems and pitfalls of various methodologies, both by their own
> experiences, and by observing the experiences of others, over a long period
> of time.
>
> I was once told that "wisdom comes by experience, and experience by lack of
> wisdom." However, the older I get, I realize that there is another better
> way to come by wisdom, and that is by listening to those who already have
> it.
>
> --
> HTH,
>
> Kevin Spencer
> Microsoft MVP
> .Net Developer
> Paranoia is just a state of mind.
>
> "John Harcourt" <JohnHarcourt@xxxxxxxxxxxxxxxxxxxxxxxxx> wrote in message
> news:0D5C8A27-99AA-4944-A270-34F6214FD1FC@xxxxxxxxxxxxxxxx
> >I don't have solid "evidence" of coding one way or the other. In most
> > instances, it's simply user preference. The framework handles both the
> > same
> > way (ok there are a few differences, but not really). You can precompile
> > your
> > pages and you can compile the code-behind.
> >
> > I didn't come from classic ASP so I can't speak for someone's been used to
> > having "inline" code. So I personally like the separation that code-behind
> > provides. And I'm not using v2 of the VS and if it provides better
> > editing/debugging capabilities, then that's great. This is one reason I
> > haven't done my hard-core coding on the page itself because it has
> > Intellisense, better debugging, etc.
> >
> > As for Mr. Rivers' complaint about ASP.NET in general as compared to ASP,
> > he
> > seems to be one who's more impressed by how fast (see his "VS.NET is 10
> > times
> > slower than VB6" rant) or how pretty his code is, rather than the
> > technology
> > advantages ASP.NET and the .NET framework provide. A rather sophomoric
> > complaint if you ask me. He should roll up his sleaves and look at the
> > technology. I would hope he'd never go back to the primitive world of
> > VB6/ASP
> > if he understood the Framework better.
> >
> > Bottom line, if you like coding on your page, great. If you like
> > code-behind, great.
> > Remember, however, if you're on a development team, pick one or the other.
> > Settle it with a toss of a coin or arm-wrestle. Then stick to it. I've
> > been
> > involved in projects where there's been a mixture and it can be confusing
> > going from one to the other and from an architecture standpoint, it's not
> > good practice.
> >
> > -- John Harcourt
> >
> > "tom pester" wrote:
> >
> >> Hi Marina,
> >>
> >> > I find the 2 arguments you listed more then enough to support the
> >> > reasons for doing it. Except with the change, that it more the
> >> > promotes thinking about these 2 things as separate. There is a lot to
> >> > be said from separating your UI from the business logic.
> >>
> >> I am all for the seperation of logic and presentation and business logic
> >> should defenetily go into its own space regardless of how small the
> >> project
> >> is.
> >> But the little code you write for wiring things up, ie that are specific
> >> to the GUI, don't need seperation cause its specific and thus not
> >> reasuable.
> >>
> >> A function that gets all orders from a database should be in a class
> >> library
> >> (and I mean not code behind).
> >> IMO A function that wires up the result to a datagrid doesn't have to be
> >> in a class.
> >>
> >> BTW Everything in ASP.NET is a class. The aspx file too. It gets
> >> transformed
> >> by a parser to a plain class :
> >>
> >> http://dotnetdan.com/articles/aspnet/FirstPrinciples.htm
> >> http://dotnetdan.com/articles/aspnet/DataBinding.htm
> >>
> >> So by that rational I do everything in a class file so I must be doing it
> >> right ;)
> >>
> >> > And sorry, but your reasons for not doing just don't make sense to me.
> >> > I don't care if I have 100 files or 50 files. You still just see one
> >> > icon in VS, and you can either go to design view, or you can go to
> >> > code. You don't see twice as many files - so who cares if in reality
> >> > there are?
> >>
> >> I hear you but I like to keep everything KISS. So there must be a _good_
> >> reason if I have to double the project in files.
> >>
> >> > In any case, microsoft didn't limit anyone to any one model of how
> >> > things should be done. If this way works for you, go ahead.
> >>
> >> The arguments you make are all solid but for me the separation between
> >> markup
> >> and wire up code (not Business Logic) is a logical one.
> >> You can make it a physical separition by splitting the file in 2. But
> >> what
> >> does it give you? IMO not more power, except for the 2 reasons that are
> >> only
> >> a consequence of making it physical.
> >>
> >> Cheers,
> >> Tom Pester
> >>
> >>
> >>

.

Relevant Pages

  • Re: TRICK: methods in ASPX pages with <%%> code blocks
    ... important "Best Practices" consideration regarding Pages is that Pages ... ..Net Developer ... > With the subject of code-behind, however, Best Practices indicate that ... >> their own experiences, and by observing the experiences of others, ...
    (microsoft.public.dotnet.framework.aspnet)
  • Re: TRICK: methods in ASPX pages with <%%> code blocks
    ... Practices" consideration regarding Pages is that Pages should not contain ... ..Net Developer ... > help determine if you should use code-behind or not. ... >> experiences, and by observing the experiences of others, over a long ...
    (microsoft.public.dotnet.framework.aspnet)
  • Re: TRICK: methods in ASPX pages with <%%> code blocks
    ... With the subject of code-behind, however, Best Practices indicate that the ... > developer, adopt best practices. ... > experiences, and by observing the experiences of others, over a long period ...
    (microsoft.public.dotnet.framework.aspnet)
  • Re: Towards a responsible vulnerability process
    ... in tremendous improvements in developer education. ... But the best example we have of code that is nearly bug-free is the ... The very best developers create few bugs, ... learn after some number of unpleasant experiences. ...
    (NT-Bugtraq)
  • Re: Javascript Best Practices Document v1.0
    ... experience with Javascript is not the norm. ... I see absolutely horrible javascript practices so often that even suggesting ... > potential of the "average web developer" and then cite their opinion ... And yet your expectation is that every web developer in the world should ...
    (comp.lang.javascript)