Re: TRICK: methods in ASPX pages with <%%> code blocks
- From: "John Horst" <jhorst@xxxxxxxxxxxx>
- Date: Mon, 29 Aug 2005 09:27:53 -0700
If I understand it right, there is a compilation difference between
inline and codebehind. I do know that you can change inline code
without having to redploy the binary in the bin folder. That might look
good from one view, but seems to come at a performance cost.
As for all the books out there, most have been written on a marketing
assumption that the reader may not have VS (thus they use inline samples
and do not show the user how to make the most of the VS IDE). I think
that assumption is probably largely wrong.
John
-----Original Message-----
From: Kevin Spencer [mailto:kevin@xxxxxxxxxxxxxxxxxxxxxxxxxx]
Posted At: Monday, August 29, 2005 8:55 AM
Posted To: microsoft.public.dotnet.framework.aspnet
Conversation: TRICK: methods in ASPX pages with <%%> code blocks
Subject: Re: TRICK: methods in ASPX pages with <%%> code blocks
Hi John,
As far as CodeBehind is concerned, I am not aware of any significant
differences in the use of it versus not using it. The CodeBehind class
logic can be in the same file as the Template code and still be
separated from it (all at the top, for example). I feel that the most
important "Best Practices" consideration regarding Pages is that Pages
should not contain any business logic, only interface logic.
--
HTH,
Kevin Spencer
Microsoft MVP
..Net Developer
Paranoia is just a state of mind.
"John Harcourt" <JohnHarcourt@xxxxxxxxxxxxxxxxxxxxxxxxx> wrote in
message news:44F6EA55-7E03-4EB3-94DA-2779FC7A61F7@xxxxxxxxxxxxxxxx
> No argument from me there.
> With the subject of code-behind, however, Best Practices indicate that
> the size and scope of a project that you're dealing (and the
> developers) with can help determine if you should use code-behind or
> not. MS didn't stop the ability from writing in-line code. Many of
> the early .NET books (even from
> MSPress) hardly mentioned code-behind at all. MS's own Matrix tool
> doesn't support code-behind. So I can hardly be surprised to see
> hoards of professional developers following Best Practices as they
> know it, but not using code-behind. Totally legitimate.
> From a personal level I've always used code-behind, even for small
pages.
> I
> just like the separation it provides. But I have a good buddy who
> wrote ASP classic for years and finds code-behind a bit getting used
> to. His first instinct is to write in-line code.
>
> cheers.
>
> "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
>> >>
>> >>
>> >>
>>
>>
>>
.
- Follow-Ups:
- Re: TRICK: methods in ASPX pages with <%%> code blocks
- From: Kevin Spencer
- Re: TRICK: methods in ASPX pages with <%%> code blocks
- From: John Rivers
- Re: TRICK: methods in ASPX pages with <%%> code blocks
- References:
- Re: TRICK: methods in ASPX pages with <%%> code blocks
- From: Kevin Spencer
- Re: TRICK: methods in ASPX pages with <%%> code blocks
- Prev by Date: Re: I have fixed ASP.NET check it out
- Next by Date: HttpHandler, User Control image display issue when deployed
- Previous by thread: Re: TRICK: methods in ASPX pages with <%%> code blocks
- Next by thread: Re: TRICK: methods in ASPX pages with <%%> code blocks
- Index(es):
Relevant Pages
|
