Code InLine Verses CodeBehind


i sr developer, new hire.  of career has been on large financial databases , has not been .net specific, although .net developer 3 years ago.  haven't touched since.

i decided out of financial industry , got hired @ marketing firm makes video-on-demand ads cable companies.  despite lack of experience .net, hired sr. level developer because of extensive database , tech lead experience.  started month ago along 2 other people.  put on same project , ended being made "tech lead" between 3 of because of ability pick on industry , business needs.

enter problem.  3 of code-behind, system architect convinced code-behind bad , code-inline way go.  disagree on several levels other 2 new people have extensive .net specific experience.  have been told write code-inline.  doesn't use asp controls, wants use html.

i inheriting import process guy leaving.  import process doesn't use ado , code-inline.  it's pretty gross.  suppose refactor (read throw out) various reason figure it's opportunity convince them of benefits of code-behind.

does have reasons why code-behind better data-driven website verses code-inline?  more part of website controls running of import process , displays data screen basic data validation.  know bunch, wanted start nothing hear reasons expressed else.

my boss's issues:
    1) thinks code behind slow
    2) worried bandwidth
    3) wants ui developers able mess our code
    4) doesn't looking @ multiple files
    5) feels code behind complicates simple issue

i know there others annoyed when harps on code-inline block out :-p.  likes mention big companies has worked , beta tested 2.0 , knows can do, applications running on 1.1 (my new stuff 2.0, don't mind long doesn't use of 2.0 tools).  don't how can uses 2.0 when it's not loaded on machine.  doesn't want use code-beside.  full-on code inline, old plain asp style.

thanks in advance comments!

1. sql injection attacks - inline coding presents many security vulnerabilities why programming ethics have changed new frameworks introduced.

2. code behind isn't slow if programmed correctly. writing memory intensive processes optimized performance. under gun, of program code optimization in mind, that's not case. if you're following else's code, it's use performance tweaks.

3. bandwidth affected server workstation. there no bandwidth interference file linked code.

4. ui developers make page pretty. don't need touch or see functional code. if anything, think ui guys/gals complain cluttering design work.

5. organization of code behind coupled oop benefit of using such approach. first of all, there no such thing "simple" issue. small project can and will grow cancer in growing business.

 

it arm wrestling match of supports benefits of either approach. say, in case, right, need figure out code should inline , should behind.

 

just twist on it,

 

adamus



.NET Framework  >  Common Language Runtime Internals and Architecture



Comments

Popular posts from this blog

Azure DocumentDB Owner resource does not exist

job syspolicy_purge_history job fail in sqlserver 2008

Trying to register with public marketplace error with 'Get-AzureStackStampInformation'