Hi, >> From quick read I did here : http://msdn.microsoft.com/en-us/library/015103yb(VS.71).aspx I have no real issue with it (it's not saying, for example, business logic goes in X area, etc).
For me, it's not about the practices the framework dictates; it's more about how the framework is designed. ASP.NET has a pipeline - modules and handlers. Architecturally, a pipeline makes a lot of sense for anything that is oriented around request and immediate response. However, ASP.NET Web Forms flattens the pipeline. Instead of going through a series of objects to process a request, you go through some modules, and suddenly end up at one big fat object - the Page. To extend it, you make use of inheritance and the template method pattern. Design pattern books and our own experiences teach that we should try to extend through composition rather than inheritance. Request processing pipelines should ideally be built through many objects (chain of responsibility, pipes and filters architecture, etc.), rather than through a series of method calls in one super object. Some aspects of how Web Forms are built do follow this pattern of composition. Control Adapters, for example, are a nice way of extending without inheritance. Controls allow composition of a page which helps, but they themselves follow a template method pattern and rely on inheritance. WCF's major advantage is that it is oriented around a pipeline. Different objects like dispatchers, message serializers, parameter validators, instance context initializers, method invokers, and so on play a part in that request processing pipeline. If you don't like any aspect of WFC, you can plug your own components into that pipeline. There isn't a single object you can point to that contains 80% of the functionality and you simply can't use WFC without it (at least not that I've seen). ASP.NET MVC is similar. Processing an MVC request involves many objects - controller factories, controllers, action invokers, method descriptor, model builders, action filters, result filters, action results, and view engines. I can provide my own implementation of any of these while still getting the advantage of the others. None of the objects are irreplaceable. In Web Forms, I either use the Page object, or I'm not using Web Forms - there's no way to substitute it. In essence, it comes down to ASP.NET MVC using lots of small objects, while ASP.NET Web Forms uses few very large objects. The large body of industry knowledge in this area tells us the former is a better design. For me, this translates to much more confidence in the framework to be able to handle my needs without me hitting a dead-end or internal class and being told it simply isn't possible to do what I want to do. Maybe that doesn't matter to you, but when it comes to my personal preferences in choosing frameworks, that's important to me. Paul On Fri, Mar 19, 2010 at 4:16 PM, silky <[email protected]> wrote: > On Fri, Mar 19, 2010 at 4:27 PM, Paul Stovell <[email protected]>wrote: > >> >> As a completely unrelated note, one of the original crew on WebForms >> sits down the hall from me - part of me wants to walk into his office, grab >> him by the collar and say 'What were you thinking?!!!' >> >> Although I personally came to dislike the Web Forms model, I do think it >> was innovative and an idea that deserved to be tried, and I'm sure the >> people who worked on it were very smart. Even bad ideas deserve a chance to >> see if they float >> > > Go on then; feel free to describe exactly all the issues with that you are > calling the "web forms" model. > > From quick read I did here : > http://msdn.microsoft.com/en-us/library/015103yb(VS.71).aspx I have no > real issue with it (it's not saying, for example, business logic goes in X > area, etc). > > > >> - that's how we learn. I think the only mistake was waiting this long to >> absorb the thinking of other communities and to try something different. >> >> Paul >> > > -- > silky > > http://www.programmingbranch.com/ > -- Paul Stovell
