.NET Questions (CLOSED)

Questions and Answers on any aspect of .NET. Now closed.

This discussion group is now closed.

Have a question about .NET development? Try stackoverflow.com, a worldwide community of great developers asking and answering questions 24 hours a day.

The archives of .NET Questions contain years of Q&A. Even older .NET Questions are still online, too.

Growing tired of ASP.NET

I'm a big fan of .NET and C# in particular. However, I'm growing increasingly tired of ASP.NET

A few of my issues:
- ASP.NET applications are difficult to unit test
- The page model makes it difficult to separate business logic from presentation code.
- Some of the features and extensions seem needlessly heavy and complex to me. For example, I took a look at ASP.NET Ajax but quickly decided I'll continue with Prototype and Scriptaculous.
- It doesn't play well with others. I tried switching from our home grown master pages implementation to ASP.NET 2.0 Master Pages but quickly found that it was munging the id's of controls inside a page. This broke much of my javascript code.

I've played around with the Castle Project tools (Monorail and Active Record) and was generally impressed. I'm a little concerned about the limited documentation and future of the project, especially in light of Microsoft's planned MVC implementation.

Ruby on Rails is tempting, but I fear it may be a Career Limiting Move.

So, what's everyone else doing or planning on doing in this area?
Kevin Send private email
Thursday, November 29, 2007
 
 
I've stayed away from programming for the Net for basically the reasons you have described. It's still an immature technology. Someday today's programmers will sit around the lunch tables telling stories - "You had Javascript (which was nothing like Java), and HTML, and Java, and SQL all in the block of code..." - the way old guys like me now talk about 80-column cards and Fortran coding sheets. However, tomorrow is not here yet, and may not be for a while.

Since you're heading towards burn out with what you are doing, try to shift gears as best can. I doubt it matters much what you change to.
Nutmeg programmer
Thursday, November 29, 2007
 
 
GiorgioG Send private email
Thursday, November 29, 2007
 
 
>>ASP.NET applications are difficult
>>to unit test

Not really in my experience. They suffer from the same issues any code does, in that if you don't properly architect it, it is difficult to unit test. But if you do things like implement MVP, etc., your business logic can be quite effectively unit tested.

>>The page model makes it difficult to
>>separate business logic from presentation
>>code.

Why's that? Not to sound like a broken record, but I've had great success with the MVP pattern here as well too.

>>Some of the features and extensions seem
>>needlessly heavy and complex to me. For
>>example, I took a look at ASP.NET Ajax
>>but quickly decided I'll continue with
>>Prototype and Scriptaculous.

This really just comes down to what you are comfortable with and what you value in an Ajax framework. There are a ton of ASP.NET frameworks out there, if you don't like ASP.NET Ajax you can use one of the many others.

>>It doesn't play well with others. I
>>tried switching from our home grown
>>master pages implementation to ASP.NET
>>2.0 Master Pages but quickly found that
>>it was munging the id's of controls inside
>>a page. This broke much of my javascript
>>code.

Sounds more like a particular issue with your javascript/previous implementation that anything really wrong with ASP.NET's implementation. Seems just as easy to say that your javascript doesn't play well with others as saying ASP.NET doesn't play well with others.

Unless you specify the ClientID for the control, .NET makes no guarantee on ID names (it does this in order to ensure uniqueness). There are numerous ways to deal with this, but I wouldn't call this "not playing well with others." I'd call this, "I wrote some code making some false assumptions which worked in my particular implementation, but now I find that those assumptions aren't true in other scenarios."

Thursday, November 29, 2007
 
 
I agree with "noname" above. Also this quote from your original post casts suspicion on your whole way of thinking about ASP.NET developement:

>>The page model makes it difficult to
>>separate business logic from presentation
>>code.

I just don't see that at all. Of all the web frameworks I've worked with ASP.NET seems to be the easiest to separate business logic from presentation. But this comes at a price. You must work WITH the ASP.NET model and not AGAINST it. Some of your comments lead me to believe that you may be the one who isn't playing nice. But it's hard to know for sure based on a single post with no details.

I also tend to believe that you will not like many other frameworks either. I've never used ROR personally. But I've used a lot of others and they all stink. Web development in general is a huge stinking pile of garbage. It is such a mishmash of different technologies and standards. ASP.NET is the only framework I've ever used that actually helped to make web development more like desktop app development. YMMV.
johnny bravado
Thursday, November 29, 2007
 
 
ASP.NET shouldn't have anything to do with your business/problem-domain logic.

I always put all my business logic in business objects in problem-domain-specific library assemblies which could be called from .NET Winforms or WebForms.

I sometimes implement little interfaces like .FromURL, .ToURL, .ToHTML or .ToControl which will turn a business object into a WebControl or something else (sometimes relying on the HTTPContext), but they can go in other classes attached to the business classes.

I've had ASP.NET pages where the entire source code was something like:

App.CurrentMeeting.Render(App.CurrentUser.Context);

Where App is a singleton, CurrentMeeting is a web-aware business object representing a conference/meeting, which contains collections of days, each of which renders itself (based on a conext to determine user rights).

You still come down to the "conduit" issue, where although you've been a good little developer and separated your layers, for a decent user experience (feedback about invalid business rules), you need to transport a lot of necessary information back and forth between the layers.  In the CSLA framework (a business objects framework), this is handled with things like the broken rules collection etc.

I'm not a strict devotee of the layers idea, since the UI does need to be aware of how to give feedback on so many business rules.  A strict interpretation of it generally leads to extremely unfriendly software which is very difficult to use.
Cade Roux Send private email
Thursday, November 29, 2007
 
 
With Monorail, you end up with methods that are easily unit tested because actions on your web pages directly map to parameterized methods. Compare this to the typical Web Forms model where you have an event handler which programatically accesses the controls and collections it needs. Not nearly as testable. While I don't dispute you can write an ASP.NET Web Forms application that can be unit tested to some degree, it doesn't happen naturally like it does with an MVC framework like Mononrail.

I understand why ASP.NET munges control id's sometimes but I also think it is an inherent problem in the design. I want my framework to stay out of my way as much as possible.

I tried to add ASP.NET Ajax to an existing web project and discovered I had to manually add a multitude of entries to web.config. With Prototype I just include the code in my page and I'm good to go.

IMHO, ASP.NET Web Forms is tailored towards the drag and drop developer and for that it does a good job. I think I'm probably just outgrowing it.

Someone else's thoughts:
http://weblogs.asp.net/hristodeshev/archive/2007/09/06/asp-net-webforms-a-shortcut-or-a-roadblock.aspx
Kevin Send private email
Thursday, November 29, 2007
 
 
The MVC project at Microsoft is their tacit acknowledgment that the Web Form / View State architecture is reaching end-of-life.

You can either work with Web Forms and fight the internet or embrace the transitory connections of the internet and drop Web Forms.
You're not paranoid if ...
Thursday, November 29, 2007
 
 
Kevin: "IMHO, ASP.NET Web Forms is tailored towards the drag and drop developer and for that it does a good job. I think I'm probably just outgrowing it."

No, I have to disagree with that. I think that ASP.NET is like VB in a lot of ways. You can do the drag and drop thing if you want and that may give the impression that it is not very accomplished. This is incorrect, just as with VB, you can, if you know what you are doing, do very advanced stuff with it.

I just don't get your original post about not being able to separate logic from design. I thought that was one of the main advantages of ASP.NET, certainly over the predecessor.

Of course, if you don't want everything that the Page class gives you, just don't use it. Create a class that implements the handler interface and go from there. One property and one method. I do that sometimes, as I don't always want all the data-binding, view state, etc.

As for AJAX, I don't actually use a framework for that. It only takes about three lines of code to fire off an AJAX request, so I just have my own tiny function to do it for me.
Entries of Confusion Send private email
Friday, November 30, 2007
 
 
@johnny bravado - "ASP.NET is the only framework I've ever used that actually helped to make web development more like desktop app development."

I think that's part of the problem. Web development _isn't_ desktop app development. Attempting to make it like desktop development causes some of the pain.

@"You're not paranoid if ..." - I agree 100%. For those that are interested in Microsoft's MVC implementation, Scott Guthrie has an excellent blog post here:
http://weblogs.asp.net/scottgu/archive/2007/11/13/asp-net-mvc-framework-part-1.aspx
Towards the end of the article you can see how the MVC pattern's better separation of concerns leads to easier unit testing. Apparently a CTP is going to be released next week.

I probably should have been more clear in my subject. I'm not tired of ASP.NET, but I am tired of ASP.NET Web Forms.
Kevin Send private email
Friday, November 30, 2007
 
 
Kevin it's already mentioned but have you checked out the usual books on MVC'ing your code? Like the books that cover CSLA.
Li-fan Chen Send private email
Tuesday, December 04, 2007
 
 
1 Cade Roux

its best to move your business logic into another DLL that can be referenced by Unit tests.

If that's not an option, look up "Web Application Project" for Visual Studio 2005.  By default, VS2005 only came with a "Web Site" Project, that was very difficult to hook up to unit tests.  The Web Application Project compiles directly to a .dll (like VS2003), which can be referenced by other projects (e.g. the tests).
Another Anonymous Coward
Monday, December 10, 2007
 
 

This topic is archived. No further replies will be accepted.

Other recent topics Other recent topics
 
Powered by FogBugz