[u]Discussion: Code-Behind vs. Inline code in ASP.Net pages</u>

(This topic will use VB as the example language.)

The .Net model promotes compilation of our code into DLLs. The DLL then contains (supposedly) platform independent binary executable code in the form of Microsoft Intermediate Language (MSIL). An installation of the .Net framework reads this MSIL from the DLL and Just-In-Time (JIT) compiles it into platform dependent machine code. This machine code now resides cached somewhere in the black box of the .Net framework ready for execution.

This model works great for .Net executables/libraries which spend their life as EXEs or DLLs on a machine.

Consider however the ASPX page. In the ideal .Net world there is an ASPX page (helloworld.aspx) and a corresponding code-behind file (helloworld.aspx.vb). When you compile your application you wrap up all your classes (standard library classes in your project and the classes for each of your ASPX/ASCX pages) into one DLL (MSIL). When IIS responds to a request for a page it takes the MSIL, pumps it thru the JIT then runs it from the framework code cache.

Alternative to the code-behind model you can put your page code right in the same file in a "runat=server" script tag. When IIS responds to a request it reads in the ASPX, takes all the "runat=server" code, compiles it to MSIL, then JITs it into machine code where, again, it sits in the blackbox framework cache for execution.

What has been gained? The machine still had to compile the VB to MSIL, we just moved the step. In a web environment this is moot because the MSIL compilation will only happen once after the machine has been re/booted, IIS cycled or files changed. Presumably the files aren't going to change a such a rate that this would become an issue.

So, putting aside the given advantages of developing with VS.Net, what do we gain from having compiled code-behind?

• Your logic is somewhat protected in the event your web server is hacked (but IIS is so secure!;) And has anyone else seen those freeware de-compilers?).

One of my personal annoyances is having to rebuild an entire solution when you only change come in one place. And I mean that I change code in an ASPX and I have to rebuild the web application (that's fine) but also all the projects that project depends on (is this really necessary?) I realize that this is only done in VS.Net. If I built the code in notepad I could be selective over which projects I recompile based on what I know I changed. I would have just thought VS.Net would have been a little smarter than that.

Opinions, ideas, criticisms, flames?

__________________
-Peter
compiledthoughts.com
twitter/peterlanoie

Hi there,

The answer is (as is often the case with IT-related questions): it depends.

Choosing between In-line Script and Code-behind pages isn't just a matter of choice between right or wrong; it's a question between applicable and not applicable, between affordable and too expensive; between messy and maintainable.

IMO, choosing the right tool for the right job is what's important. If all you need to do is put up a couple of pages showing a static Who-Is-Who on your corporate Intranet or the Restaurant's menu, building an entire VS.NET solution, deciding on Namespaces, Code-Behind organization, etc. might be too much overkill. In that scenario, Inline-script should work perfectly. It allows you to quickly throw a few pages together, debug and fix them in no-time and put them on-line.

However, if you need to build a complete Intranet or Web-application, where a team of developers is working on, choosing for a fain-grained application architecture where UI is separated from Business Logic that in turn is separated from Database connectivity, is the way to go. I think this has the following benefits:

1. Visual Designers are not in conflict with coders. (I don't believe in the hyped magic words: "Visual Designers and Coders can work together on a page", but at least it will stop the Designers from messing with my buggy code, and it might stop me from adding a cellpadding="2" to a nice design, just because I think it improves the layout of my data ;) )

2. Code Reuse. By adapting the code-behind model, your mindset will be focused on code-reuse earlier in the development process. I have seen lots of websites that have the same functions, like GetPageName, GetCustomerName, or whatever defined in multiple pages, that basically follow the same implementation. By implementing all your code in code-behind you are likely to group related functionality in their own assembly, Namespace of whatever logical grouping you might come up with. This increases team-productivity as it minimizes the chances that individual developers build their own similar functionality.

3. For VS.NET projects: Intelli Sense, statement completion, and lots of other features are really improving productivity. Not only do they allow you to program faster, they also make you program smarter as they show you available methods, properties, etc. that a certain object or class exposes. You won't find this in text-based editors and it isn't available in an In-line script page.

4. Design-Time error catching. Waiting until runtime to notice an error, might cause situations where your client sees the error, and not the developer. By compiling at design-time, you are likely to catch a lot more errors beforehand....

5. Templates / Master Pages. Although Master Pages are scheduled for ASP.NET 2.0, you can now already use some sort of a template model. A very interesting thread at ASP.NET shows at least two ways to create a reusable template class. Some inspiring concepts have been introduced there, like the Page base class that your page can inherit its visual appearance from to have a steady look-and-feel throughout the site.

Of course, budget is also a very important issue. If you or you company can't or won't afford the price for Visual Studio, you're out of luck. Even then, as has been mentioned here before, you still have the option to use code behind and compile your application before you put it live. This may be a bit more work, especially in the beginning, but IMO it will pay off in the long term.

To overcome the heaviness of building solutions using VS.NET you could try the following:

1. Create a solution during development that contains a web application and one or more Class Libraries that contain your business logic and data access layers. During development, rebuilding the entire application shouldn't be too much a problem (besides, the Build command just recompiles changed code; using Rebuild will force VS.NET to recompile the entire application).

2. Once the BLL and DAL are stable, create a new Solution that has the Web Application as a single project, and then use file referencing to point to the (Release) build BLL and DAL layers. This way, they won't get recompiled every time you compile your web application.

In this scenario, you would still need to recompile the entire web app, but by separating out Business Logic and Data Access to their own assemblies, you'll minimize the code in the web application.

In short, I believe that Code-Behind is a model that makes very much sense. It’s cleaner, clearer, easier to maintain and reuse, and generally allows for code that is easier to understand and debug.

However, the cost of setting up a project that uses this model may not always outweigh the benefits. As is often the case with design issues, it’s important to compare the benefits and costs / risks of any design solution and then decide what’s worth choosing for.....


Imar


---------------------------------------
Imar Spaanjaars
Everyone is unique, except for me.

Hello...
I understud very well why both things important in perticular usages.

But i find one more syntex ...

src="file.aspx.cs"

so, how its different then Codebehind="file.aspx.cs"

---- what i thinks is....

1)when we use codebehind it find related compiled bin/projectnm.dll...
and then execute it.

2)If we use src
 when .aspx file will request it first compile src="file.aspx.cs" then execute it.
so one more task comes here. + when we use src="file.aspx.cs" we also needed perticular "file.aspx.cs" on server. But in codebehind it's not require.(codebehind require only .dll or .exe)

--------- end ---------

welcome your thought.

Regarding the "src" attribute of the @ Page directive:

When you use non-compiled code-behind (or NCCB) you need to put your code files on the server. This has the advantage of easy "xcopy" update/deployment, but the disadvantage of not being precompiled. When the page is compiled on the fly, it has to be compiled from the written language (VB/C#) to MSIL, and then JIT-ed to the runtime. Precompiling to the DLL gets you past that first step. Because every page that you have would need to be "precompiled" (before the JIT compile) at request-time, each page's first request would be slowed down a bit. Now this might not matter too much for you. I know that on my site, with it's limited activity (:() the compiled code in the runtime cache gets dumped regularly, so using NCCB would slow my site down noticably.

One thing I'm not sure of but would like to find out about is how much of a compiled DLL gets JIT compiled when a class from it is requested. This could have a major impact on things in general. If all the assembly code gets JIT compiled when any of its classes are consumed, then the whole site will run faster after the initial request. This would prove to be a significant performance increase compared to pages using NCCB.