Questions and Answers on any aspect of .NET. Now closed.
Joel's article last month, Language Wars http://www.joelonsoftware.com/items/2006/09/01.html states that using more than one form in an ASP.NET page is desirable. I've pondered this for quite some time. Does this mean that all pages which use more than one form do the following:
1) They don't use post back?
2) They and their controls don't run at the server?
3) If not 1 or 2, then how?
The reason I'm asking is that someone else mentions that FogBugs doesn't do any postbacks but rather every page posts to another, and this is desirable for ASP.NET development. Of course this sounds like PHP or ASP.
Am I to understand that there is a school of thought saying that ASP.NET should be used like PHP, without postbacks (It doesn’t seem like postbacks can work when using more than one form as mentioned above).
I appreciate insights anyone has. I have been working with ASP.NET for four months and am just starting a big project. I don't want Microsoft to lure me with easy technologies, and then force me into a corner. I want to use ASP.NET, but in a flexible manner. I have more questions, but would just like to understand what the alternatives to postback are, and why/how to use ASP.NET without it.
Dino Esposito does a lot of good hacks and been writing good articles for a long time.
The following article gives ideas to work around the single form limitation in ASP.NET:
The above article is three years old and what Joel mentions in his article is a concern for many ASP.NET developers and may be addressed by Microsoft soon. Dino's blog entry about Atlas and the viewstate may interest you.
Since you say the above, I think you understand objectively what goes into ASP.NET and what doesn't. I am not sure but I don't think there's more to what goes into making ASP.NET work for you.
A couple of reasons why I think Microsoft comes up with an environment like this is that they use the experience they already have in developing tools and that they bet that the bandwidth will be increasing.
The environment is similar to what was in Visual Basic before web programming was widespread.
The main idea behind features like this, I think, is that like the chip got better consistently mirroring Moore's law, the bandwidth is also expecting to increase. The way a chip would be slowed before, bandwidth is used up now. When we have lesser bandwidth, we'll do more programming passing session values around and all. But that's made easy but we are given the baggage of viewstate. People use it without knowing what they are getting into. Under the hood, they are making it lighter and bandwidth will also increase. So things would come to a state where it really wouldn't matter if viewstate is used or not. The overhead will become negligible. Of course, newer features will then take up the resources which are then limited.
I'm sorry that this post sounds like a rant and if it sort of goes off track. My current perspective is this and I think that the time spent more on this may turn out to be not very useful.
"I wish there was an unbiased book describing how to use ASP.NET in your webapps rather than how to create webapps with ASP.NET."
1) Stick with quality code conventions and practices. (IE use MVC instead of .aspx/heavy-handed code behinds.)
2) Shy away from .Net controls and the visual designer. (IE just use html elements instead of asp:foo - especially data controls!)
IMHO, ASP.NET is a wonderful environment for web-apps, as long as one does not implement as Microsoft or the multitude of online tutorials tell you too. Obviously, YMMV, but the projects I've been involved with that strictly adhered to the above suggestions were more successful and more enjoyable.
Monday, October 09, 2006
In response to the "stick to MVC/don't use System.Web.UI.*" advice, I'll say this:
If you and your staff, are former struts developers, or otherwise used to working with MVC frameworks and are coming to ASP.NET by way of some external requirement, then you may be able to proceed in that direction.
The ultimate problem here is that the use of these techniques is not nearly as widespread in the .NET world, and finding programmers who can hit the ground running with an MVC framework (like perhaps Maverick.NET) in .NET is devastatingly hard. Since Microsoft's own literature, not to mention the vast majority of other resources (books, web sites, etc), follows the System.Web.UI.* doctrine, the choice to use a completely different framework is not without significant risk. I'd say unless your average developer is staying in their position (i.e. same project/product) at least two years, then the advantages of using a non-mainstream framework are probably offset, for the most part, by the problem of staff turnover.
This isn't to say that MVC on ASP.NET is or isn't the right decision, but you will have a harder time staffing up and harder time getting official developer support for a .NET based web app if you choose to abandon the MS "way" of doing things. Another alternative is to use the System.Web.UI controls but rein yourself in, and only use them in a way that corresponds to the development methodology that you choose. It's possible to make websites using S.W.UI.* that are MVCish in structure and behavior. It's just not straightforward and it takes thought and effort.
I look at MVC frameworks on .NET as similar to the Mazda RX-7/8. If you are a true believer in, and enthusiast for the Wankel Rotary Engine, then by all means buy one, drive it, enjoy it. But be prepared for the reality that very few mechanics can work on it, and those that can, know they're scarce, and will charge you out the nose. Your enthusiasm for fringe application environments may end up costing you more than it saves you.
"Since Microsoft's own literature, not to mention the vast majority of other resources (books, web sites, etc), follows the System.Web.UI.* doctrine, the choice to use a completely different framework is not without significant risk.
It's possible to make websites using S.W.UI.* that are MVCish in structure and behavior. It's just not straightforward and it takes thought and effort."
Agreed on both accounts. In my cases, I've had the benefit of working with someone who is used to the MVC paradigm regardless (sometimes in spite of) various languages/frameworks. Thus, I have yet to use an actual "framework" per-se with APS.Net, but more a strict MVC organization of code/classes/behaviour/etc.
All of our *.aspx and *.ascx files have "code-behind". But rather than a 1-1 relationship, we avg probably a 2-1 page to class ratio. (via the Inherits page attribute rather than CodeBehind). And such classes are mostly Bean-like, shallow, accessors. All complimented by full controller and dao layers.
In any case, I certaily agree such an approach is not without risk, especially (as you note), the vast majority of literature will be of no help in such efforts.
(P.S. Speaking of MVC and .Net, I'm keeping an eye on the MonoRail project.)
Monday, October 09, 2006
> IE just use html elements instead of asp:foo - especially data controls!
I'm a novice at ASP.NET.
I've just noticed that adding an empty (i.e. bound to no data, and therefore invisible in the browser) TreeView element to the page, such as ...
<asp:TreeView ID="TreeView1" runat="server">
A simple custom control class (derived from WebControl) adds no such complexity.
My conclusion then is to consider writing custom control classes (derived from WebControl) instead of using 'heavier' prebuilt controls such as TreeView.
This topic is archived. No further replies will be accepted.Other recent topics
Powered by FogBugz