Sponsored By Aspose - File Format APIs for .NET

Aspose are the market leader of .NET APIs for file business formats – natively work with DOCX, XLSX, PPT, PDF, MSG, MPP, images formats and many more!

ASP.NET 2.0 Is NOT a Silver Bullet

Before the first concrete information about 2.0 came out, promises about massive code reduction were being made.  “I can’t say too much at this point…one of our aggressive goals is to reduce the number of lines of code between v1 and v2 by 70%”. Every book, article and blog quoted that oft-repeated line from the ASP.NET development team.  Even when 2.0 was still a year away, we were told that goal was almost reached. Glory hallelujah!. Fast forward to today, months after the 2.0 RTM and you’ll quickly realize there is no silver bullet (heck if OO couldn’t do it for us, we were fools to ever believe ASP.NET would).

Every developer thinks his or her code is going to save users and clients 70% of their time. Every time I build a new application I envision mass-workload reductions and international “Karl Seguin” holidays. It’s some type of global developer hubris (in the modern sense, not the Greek one), and Microsoft developers are far from immune. But aside from the forgivable enthusiasm, why aren’t I (and I assume most people) writing 70% less code?

First, I consider myself an ASP.NET developer, but I probably spend less than 25% of my time in aspx and codebehind files.  Most of my time is spent in my domain, data access and data layers. Much time is sent writing modules, handlers and server controls. Even if I managed a 70% code reduction, it’d only put a small dent in my overall coding.

That point aside, I do think some of the time saving features were just blown out of proportion.  One of my favorite example is everything revolving around the new Membership provider.  Yes it’s great and yes I use it. But I needed it’s functionality over 3 years ago, so I built my own. I was already saving code by using composite controls for my login, registration and password retrieval along with a flexible business and data model. The 2.0 stuff is better than mine, but it doesn’t save me from writing any code I didn’t already have.

Secondly, much of the reduced code comes with strings attached. Take the built-in paging and sorting of the datagrid or the gridview. You’ll end up paying a huge performance hit for any medium-to-large data set (not necessarily DataSet). Anyone who’s had to page results with any type of performance implication _always_ does this at the data layer. Then there’s the SqlDataSource, which I love picking on. Sure you can write this application with few lines of code, just forget everything you ever learnt about programming.

Thirdly, declarative code is still CODE. Not to be rude, but it’s bullshit that 5 lines of code to declare my ObjectDataSource in my aspx should be considered as less code than the 2 lines it took to bind to my [highly reusable] business layer. Yes, a designer generated it (btw, clicking next 3-4 times still takes longer to do than to write those 2 very short lines), but a human will have to maintain it.

You want to know what really makes me productive? Spending time upfront to properly architecture my application.  Making use of libraries, such as Log4Net and Patterns and Practices code block (along with my own, for example localization). Generics are the real 2.0 feature that save me a ton of code (nullable types are a let-down).  Tools like SourceGear’s vault, JetBrain’s Resharper, DevExpress’ CodeRush and CodeSmith Tools’s CodeSmith are key. Not to mention everything made by Red-Gate.

It seems that the only sites that benefit from any code reductions are either the ones being developed by bad programmers or the ones that had little code to begin with. Sure, I’ll drag and drop a couple controls for my dad’s webpage, and it’ll save me 30 minutes – great.  But for the sites I spend months working on, saving 30 minutes upfront is going to violently bite me in the ass.

The ASP.NET team is passionate and excited about what they do. That’s really all I’m accusing them of. I don’t feel lied to whatsoever. I am somewhat skeptical of the MS Marketing machine (95% caused by longhorn, 5% from continuously losing anti-trust lawsuits), but I don’t think that’s intentionally what happened here.

I do have two fears. First it’s that the ASP.NET team may be disconnected with .NET developers in some respect (a topic I want to explore in greater depth another day). More of a concern is that little material is created from the ASP.NET team about sound design and architecture. Every time a demo, tutorial or whatever includes an SqlDataSource, an angel looses its wings.

By way of closing, it must be stated that I hate posts with negative undertones that start off with an apology – they always seem so fan-boyish. The phrase “don’t get me wrong, I love XXX; but…” makes my ears bleed. Obviously I feel my complaint is legitimate (I hope if you disagree you’ll let me know), but I don’t think it’s a huge issue, more like food for thought.

This entry was posted in Uncategorized. Bookmark the permalink. Follow any comments here with the RSS feed for this post.

13 Responses to ASP.NET 2.0 Is NOT a Silver Bullet

  1. Scott Muc says:

    Great post. I really liked the line:

    “Every time a demo, tutorial or whatever includes an SqlDataSource, an angel loses its wings.”

    I have it as my MSN description right now.

  2. jlynch says:

    Karl,

    I have to disagree with your main points. I just rewrote a B2B Commerce Server 2002 application including custom BLL and DAL and moved it from CS2002/ASP.NET 1.1 to CS2006/ASP.NET 2.0. The total number of lines of code written (.aspx, code-behind, custom .cs, etc.) dropped by more than 50%. Since I documented my original project for an MS ROI case study I can also state that the total man-hours required dropped by more than 30% even though we had to “learn” all the new stuff in ASP.NET 2.0. Our DataSets are medium size with several thousand rows and the ObjectDataSource paging provides us with excellent performance so far.

    I don’t think there is any silver bullet for web development but ASP.NET 2.0 is certainly a step in the right direction.

    Jeff

  3. scottgu says:

    To Brendan’s point above — the web project system changes caused a lot more pain then we wanted for enterprise customers.  We made a mistake with that.  That is why we’ve made the VS 2005 Web Application Project available as a web download now and will be rolling it into SP1.  That addresses the issues you listed above with ASP.NET compilation, web projects and refactoring inside the IDE.  If you haven’t tried out the latest build yet, I’d strongly recommend spending sometime with it (tutorials are online here: http://www.asp.net/webproject/Default.aspx?tabindex=0&tabid=1 and more info can be found here: http://weblogs.asp.net/scottgu/archive/2006/04/05/442032.aspx)

    Hope this helps,

    Scott

  4. scottgu says:

    Productivity doesn’t come for free, you do still need to learn new APIs and concepts to often get it.

    To use your example above with Master Pages, you need to spend 30-60 minutes reading about Master Pages before you can become a expert with it.  But once you do understand the concepts (which are fairly straight forward to grock), I do think you’ll see productivity benefits from it almost immediately.  It also integrates much nicer with other features (and VS 2005) that any extension you could have built with V1.1.

    There are a lot of new APIs in V2.0, and so while it might at first appear that you are spending a lot of your time just coming up to speed with them, the knowledge should pay a lot of dividends going forward.  I just spent 15 minutes looking for articles on the web for a guy who is writing a V1.1 Application_AuthenticateRequest event so that he can decrypt a roles cookie retrieved from his database and set the IPrincipal context for the request in a secure and efficient way.  It is going to take him a few hours to get this working and tested in V1.1 (let alone getting the Roles schema built and tested and working solidly and scalably on the backend).  Him being able to just write Roles.AddUserToRole("user", "role)" in V2.0, and not having to-do any more on the front-end to enable it, is going to be a big timesaver in the future.  I think there are a ton of features like this (SqlCacheDependency, HealthMonitoring, SiteNavigation, etc) that when added to your toolchest will save a ton of time, both in coding, but more importantly in testing and fixing both functional, performance and security bugs (which is where the bulk of time is spent for most projects).

    The fact that you can always drop-down and tweak the provider if you don’t like the implementation, also means you can leverage both the benefits of productivity + extensibility with this model.

    Hope this helps,

    Scott

  5. test says:

    test

  6. Brendan says:

    Karl,

    I agree more than words can express. Not only have our team’s productivity gains been nil, I think I can safely say that we’re struggling to become as productive as we were with ASP.NET 1.1. This isn’t because of ASP.NET per se, but all of the brokenness that comes with VS.NET 2005, the ASP.NET Compliation model, Web Projects and Refactoring.

    To me, the biggest productivity gains from all the 2.0/2005 stuff? Generics, SQL Cache Dependencies, and ATLAS… I know a random handful of stuff, but everything else has really been more of a hassle than anything else…

  7. karl says:

    Scott, sometimes I think ur a machine…lol

    Nevertheless, I still think that for large applications, the productivity gain is almost nil. Even for large projects being converted over to 2.0 from something other than 1.1, the bulk of the effort won’t be related to ASP.NET.

    Sure, there are _a lot_ of small projects, but how much productivity gains can you squeeze out for them? Maybe ASP.NET 2.0 was the push to get the most out of it, but I’m thinking you must be seeing some serious deminishing return. What’s the gain-to-effort ratio of further optimizing 5 day long projects?

    Using the built-in MasterPages in 2.0 and MetaBuilder’s in 1.1 didn’t save me any time. Using the built-in Site Navigation vs SkmMenu’s or Telerik (or ComponentArt) doesn’t save me any time. You still need to learn the api.

    I’ll hold off commenting on the localization stuff, except to say my first articles dealt with localization, they are still my most popular and the daily emails I get about them highlights that the built-in stuff doesn’t work.

  8. Eric Marthinsen says:

    I always felt the ASP.NET team was upfront and honest about the fact that applications that required more fine-grained control of performance, functionality, and architecture would only experience modest code reduction.

    I do think that the 70% reduction was more geared towards smaller site, internal apps, etc. which, as an enterprise developer, sort of bums me out, but we are in the minority when it comes to developers.

  9. scottgu says:

    Paging support with the GridView and DataList controls can actually be done super efficiently and at the data-tier level (so you are only grabbing the 10 or so rows from the database that you need — and doing the paging logic within the database).

    Here are two articles I wrote that show how to-do this cleanly and efficiently using the ObjectDataSource control:

    http://weblogs.asp.net/scottgu/archive/2006/01/01/434314.aspx

    and

    http://weblogs.asp.net/scottgu/archive/2006/01/07/434787.aspx

    Much of the productivity wins with ASP.NET 2.0 come by having built-in implementations of common services/features in the box (Master Pages, Localization, Health Monitoring, Membership, Roles, Profile, Web Parts, Site Navigation, etc).

    If you’ve already written your own implementations of all of these services with V1.1, then obviously the benefit of having built-in ones to take advantage of is lessoned. The benefit for new apps, though, is that people can take advantage of these without having to write this — and they are industrial strength tested and designed to perform and scale really well (two big things that people writing their own implementations have to grapple with today).

    The other benefit I think you’ll find is that the level of integration with these new features is high, the features are designed to work well together, and with the provider model you have a lot of flexibility to tweak/customize them if you want. We recently shipped the source code for the providers on the web here: http://weblogs.asp.net/scottgu/archive/2006/04/13/442772.aspx which makes it pretty easy to customize any of the existing implementations to your hearts content — while preserving the API and programming model.

    Hope this helps,

    Scott

  10. Alex Lowe says:

    A few thoughts:

    *Your perspective is valid and would be 100% correct if the only applications built were ones that were used in high performance situations/environments. Of course, that is not even remotely close to true because there are thousands and thousands of applications that are used by 1, 5, 25, 50, 100 people total. These applications and scenarios are just as valid as your "enterprise" scenarios albeit they don’t apply as much to you.

    *There are tons of developers/development teams who don’t have a library they’ve already built. They are migrating from ASP or are new to the .NET world all together.

    *The idea that every application should be architected to scale to "enterprise levels" is ridiculous. I don’t care about the few applications that start out in the workgroup and then go "global" within the company as the number of those applications is incredibly small. What I call the "we can optimize so we are king" group has pushed this mantra the last ten years but only to the detriment of virtually every project schedule created in that same time period. There are thousands of applications that can and should be written using the "crappy" SqlDataSource control, DataSet, "improper" paging, etc. Don’t dictate your needs on everyone else. I recommend reading the book "Getting Real" by the folks at 37signals.

    *The ASP.NET team is NOT the right people to make demos or give prescriptive guidance in many instances. The ASP.NET team should be focused on building unbelievable IDE features/experience and making a highly optimized framework for the rest of us to build applications on top of. Let a group of folks who work in the "real world" write samples and prescriptive guidance. Generally, this is what is being done but more could certainly be written. The Patterns & Practices group could do more in this regard.

    *I don’t believe anyone from Microsoft can tell me how to architect my application. They don’t know my problem domain. They don’t know lots of things about my environment. I won’t make blanket statements or expectations that they tell me any of that. I do expect some generic forms of guidance regarding architecture and hopefully that is what you are looking for too.

    *I don’t believe the ASP.NET team is disconnected from .NET developers anymore than the C# team is disconnected from .NET developers. Both teams are building great products for their respective role in building .NET applications. I would agree with someone who said that the .NET framework folks could build more tools to help me in my data access and business layers. In my opinion, the fact that those tools don’t exist doesn’t mean the ASP.NET team is disconnected from .NET developers.

  11. Eric Schatzschneider says:

    ASP.NET 2.0 is not the only .NET technology that has this problem. I been working with WinForms and it has a simular issue. All the code generated databinding that is done with WinForms is all in a single layer. I had to rip it all out and write it from scratch.

    Microsoft needs to start thinking about code maintenance and architecture not just RAD. All this features are just RAD sugar, but doesn’t give any long term value.

    BTW, I never didn’t believe that ASP.NET 2.0 would save me 70% of my code.

  12. Paul Wilson says:

    I totally agree. I do really like ASP.NET v2.0, but anyone doing things right isn’t going to save much (if any) time. Most of us that knew what we were doing have been using some form of page templates (if not a v1 of MasterPages) all along, and things like themes were always trivial. The best things to me are the provider-based APIs, but it actually takes more time (not less) if you do what is best, which is to create your own custom provider against your own schema. As for the ASP.NET team, I do think they spend too much time thinking about small hobbiest sites, but I also do understand that they must serve them too — the problem is that they don’t also have any “real” demos or advice. And the book authors and trainers are pretty much guilty of the same thing — they water most everything down to the hobbiest or newbie level and give very little (if any) “real” material.

  13. Jim Losi says:

    < <"Every time a demo, tutorial or whatever includes an SqlDataSource, an angel looses its wings" >>

    HERE HERE!! I tell you, when I started learning 2.0 I was all for less coding until I really started reading up on best practices. It was then I began to curse the webcasts that showed “easy way” out. It’s almost like MS is hooking you with “flair” and then you find out that if you really want to make good stuff you still have to spend gobs of (well spent) time designing .

    All I know is that I kept nodding my head with each paragraph you wrote.. now my neck hurts :)