Comparing a S#arp Architecture ASP.NET MVC Project to Classic ASP.NET with LINQ to SQL

About a year ago I assisted another developer with setting up the initial project structure for a risk management system using S#arp Architecture version 0.6 which included Spring.NET with that version.  Due to time constraints I couldn't assist with anything else (e.g., design decisions, #Arch best practices, OOP structure, etc.) for the remainder of the project; so he was on his own after we got the intial project structure set up.  Towards the end of the year, a second risk management system was developed by the same developer with very similar requirements.  The major difference the second time around was that I couldn't assist whatsoever.  The developer, who openly admits a very strong aversion to anything opensource-and-not-stamped-by-the-Microsoft-mothership (e.g., Spring.NET, NHibernate, #Arch, NUnit), chose to rewrite the application using classic ASP.NET and LINQ to SQL since I wasn't going to be involved at all.  When he finished the project, he was kind enough to send me a compartive analysis of the two projects including cyclomatic complexity and basic LOC counts.  The results were pretty dramatic.

I'll admit that I haven't looked into the code to determine why some of the numbers are the way they are.  But keep in mind that the scope of both projects was very similar and the numbers, outside of the LOC which I'll discuss below, should be seen as comparing apples to apples.  Keep in mind that these numbers were collected by someone who is very biased against the use of opensource tools and was hoping to conclusively show the benefits of going with "pure Microsoft."

Project Metrics from his S#arp Archicture 0.6 Project

Project Metrics from his ASP.NET with LINQ to SQL Project

 

When looking into the numbers further, we recognized the classic ASP.NET project had a large number of additional content pages which were not in the project built on S#arp Architecture.  So to make it fair, we dropped all of the pages, along with an Excel integration module.  This removed about 15,000 LOC from the ASP.NET project.  So in the end, the adjusted LOC for the ASP.NET with LINQ to SQL project was 15,848...nearly a magnitude difference from the S#arp Architecture project.

You'll notice that there are some metrics which are worse on the S#arp Architecture project than the ASP.NET project and I haven't looked at the code to determine the cause behind any of the metrics, whatsoever.  But all in all, I was pleased with the results of the comparative analysis between a S#arp Architecture project and an ASP.NET with LINQ to SQL project, both having very similar requirements and written by the same (not me) developer.

Billy McCafferty


Posted 05-15-2009 2:23 PM by Billy McCafferty
Filed under:

[Advertisement]

Comments

DotNetShoutout wrote Comparing a S#arp Architecture ASP.NET MVC Project to Classic ASP.NET with LINQ to SQL - Billy McCafferty - Devlicio.us
on 05-15-2009 8:45 PM

Thank you for submitting this cool story - Trackback from DotNetShoutout

Fred Morrison wrote re: Comparing a S#arp Architecture ASP.NET MVC Project to Classic ASP.NET with LINQ to SQL
on 05-15-2009 10:44 PM

Imagine what the numbers will be like once the issues with T4 Toolbox (latest version breaks S#arp Arch) and VisualVSN (S#arp won't play nice with others) are fixed.  Having intellisense in the S#arp scaffolding templates would be nice too.  Throw in the nice way Dynamic Data builds View pages from component controls, and we can start calling it Razor S#arp :-)  S#arp has head start on EF 4.0, but can it stay far enough ahead to remain a compelling alternative to the coming EF 4.0?

Billy McCafferty wrote re: Comparing a S#arp Architecture ASP.NET MVC Project to Classic ASP.NET with LINQ to SQL
on 05-16-2009 11:07 AM

Who says there won't be a S#arp w/EF? ;)

Parag Mehta wrote re: Comparing a S#arp Architecture ASP.NET MVC Project to Classic ASP.NET with LINQ to SQL
on 05-17-2009 8:10 AM

Although the benefits are great, must remember he is using LINQ+SQL=> that itself is generating 10k LOC.  I didn't understnad why there is such huge difference in Web between S#arp and Pure ASP.NET ?

Luis Abreu wrote re: Comparing a S#arp Architecture ASP.NET MVC Project to Classic ASP.NET with LINQ to SQL
on 05-18-2009 4:59 AM

I agree with a previous comment which mentions the excessive number of lines generated by the LINQ to SQL generator. I guess that what would be important would be to see the number of lines of code generated in a well-built ASP.NET web forms app vs a well-built ASP.NET MVC app. I'm thinking that MVC would have more lines here, but web forms wouldn't probably reach the same code quality as the one you'd get in MVC.

Eric wrote re: Comparing a S#arp Architecture ASP.NET MVC Project to Classic ASP.NET with LINQ to SQL
on 05-18-2009 1:05 PM

Comparing apples to rocket sleds?

I guess we'll all just have to take your word for the discrepancy in number of lines of code...  An in-depth examination and comparison of the code would be much more interesting and convincing than a raw listing of the number of lines of code.

What about using the XML Mapping Scheme option for LINQ to SQL?  How many lines of generated code does that get rid of?   Were other "generated" files (example: Page.aspx.designer.cs) excluded from the line counts?  I'm really curious why the ASP.NET Web Forms project is so large compared to the other one?

You could really make this into a great series of articles if you have the time and desire to do so!  ;)

Billy McCafferty wrote re: Comparing a S#arp Architecture ASP.NET MVC Project to Classic ASP.NET with LINQ to SQL
on 05-18-2009 10:03 PM

Hi Eric,

When I get some time I want to dig into more to determine the cause behind some of the metrics.  Although lines of code is cool to see, I'm also very interested in the cause behind the complexity and maintainability numbers.  A series of posts on the "digging in" would be very interesting indeed.  Admittedly, the SharpArch libraries hide a lot of the lines of code that would typically be in a project.  But again, I think a more careful examination of the comparison as a series of posts would be much more informative.

<K>Illvminati wrote re: Comparing a S#arp Architecture ASP.NET MVC Project to Classic ASP.NET with LINQ to SQL
on 05-20-2009 4:34 AM

I wouldn't say biased...  The largest difference in the implementation was around accomodating an intricate interaction requirement for the interface, while meeting a scalabilty/perf requirement: MAX data return per call ~32kb (avg < 16kb) and a response time of <1sec...  The data interactions were ultimately streamlined such that interaction events were all handled (sort, page, filter, ...) with the corresponding orderby, skip, take X, etc.  That accounts (understandably) for the order of magnitude diff.  The normalized stat's are mos def apples to apples.  The current manifestation of MS MVC and several flavors of ajax/client driven interactions require a great deal of care to address web 1.0 issues - from tampering, injection, replay, inference attack, esc of privi's, XS* exploits, UX browser conventions, caching...  Also, async operations on the same request|response action for the pure rendering mechanisms aren't there yet either for MVC.  "Classic" ASP.Net in this case, for the app mentioned, caused Anti-DRYness very quickly while the MVC turned into lasagna when implementing a simple grid sort...  A batched update of "tree" data based on concat'd element names (to be parsed) was ~as bad as the MS control tree (minus the intellisense) and def out of bounds for unit TDD - integration test realm there.  On the other hand it drives me nuts to see a .25MB page of just a "simple" TOC tree *without viewstate enabled*.  ---I will admit bias/prefs in a few regards: 1) Model driven dev POV (clean gen'd tsql, lean projections, min DB data transfer, min round trips DB|web|browser) 2) any input from the (http) client cannot be "trusted"  3) "B- "tools are better than "A+" tools if the are fully integrated (into the IDE, etc) and cost $0 - open source or MSDN Sub... 4) Guideline - the app arch should be solid for the equiv platform & hardware lifecycle of ~3 years...  I appreciate the M + C, but not so much a fan of the V (tools/helpers have to evolve).  All time "best" V approach - HTC with xml|xslt|xmlhttp data loading + client engine rendering with just enough dhtml to support reasonable interactions.  BTW - the interface required a "turbo tax style interview process" around a biz process workflow - which was the source of the dropped 15K LOC in the calculations.

So core + controller + web *versus* core + web for a fair LOC comparison (minus the turbo tax part of course).

Naveen wrote re: Comparing a S#arp Architecture ASP.NET MVC Project to Classic ASP.NET with LINQ to SQL
on 06-09-2009 9:22 AM

hi this is naveen,

i am new to dotnet 2008, i don't no how to work with MVC with asp.net please offer me a solution to work with it.......!

with regards,

Naveen. N

Billy McCafferty wrote re: Comparing a S#arp Architecture ASP.NET MVC Project to Classic ASP.NET with LINQ to SQL
on 06-09-2009 11:42 AM

Well, you can start here, of course :)  code.google.com/.../sharp-architecture

Social bookmarks wrote re: Comparing a S#arp Architecture ASP.NET MVC Project to Classic ASP.NET with LINQ to SQL
on 03-24-2013 12:21 AM

3h78Na I really liked your post.Much thanks again. Awesome.

About The CodeBetter.Com Blog Network
CodeBetter.Com FAQ

Our Mission

Advertisers should contact Brendan

Subscribe
Google Reader or Homepage

del.icio.us CodeBetter.com Latest Items
Add to My Yahoo!
Subscribe with Bloglines
Subscribe in NewsGator Online
Subscribe with myFeedster
Add to My AOL
Furl CodeBetter.com Latest Items
Subscribe in Rojo

Member Projects
DimeCasts.Net - Derik Whittaker

Friends of Devlicio.us
Red-Gate Tools For SQL and .NET

NDepend

SlickEdit
 
SmartInspect .NET Logging
NGEDIT: ViEmu and Codekana
LiteAccounting.Com
DevExpress
Fixx
NHibernate Profiler
Unfuddle
Balsamiq Mockups
Scrumy
JetBrains - ReSharper
Umbraco
NServiceBus
RavenDb
Web Sequence Diagrams
Ducksboard<-- NEW Friend!

 



Site Copyright © 2007 CodeBetter.Com
Content Copyright Individual Bloggers

 

Community Server (Commercial Edition)