I do not think ASP.NET needs fusebox like constructs because it is already based on a design pattern called Page Controller Design Pattern. A code behind page for a view can act as a controller and can call methods of other controllers (a database controller, a domain controller, etc.) or methods and properties of other objects (a model object, a view object, etc.). Fusebox concept is a derived from Front Controller design pattern. In ASP.NET, a front controller can be written as a dll. For a complex application, the front controller will call command controllers to accomplish specific user actions. A config file in XML will map user actions to various command controllers and the front controller can use reflection to instantiate an appropriate command controller (do we see the similarity in fusebox?). What ASP.NET needs is an extensive framework, like Strut (for Java).
[EMAIL PROTECTED] wrote: > This post was put on the asp_fusebox list and it made me really think > harder about fusebox and how appropriate it is for other language > platforms. Originally fusebox's strengths was that it would be used for > other languages but clearly this is not being done actively. Now the > question I have is this "Is fusebox really just a crutch for non-OOP > scripting languages?" > > ----- > > Date: Fri, 17 May 2002 12:22:04 -0700 > From: Bret Van Horn <[EMAIL PROTECTED]> > Subject: .net progress, further thoughts, no answers > > > Since I've sort of been under the gun to find a fuseboxish solution for > .net, I hacked a lot on it this week and have a *VERY* rough fusebox 2 > scheme working. I can pass a querystring variable of fuseaction, have it > passed to a fusebox user control, along with some other global > variables, > then the fusebox control parses an fbx_switch.xml document to find the > include file. > > I then took it a tiny bit further and had the fusebox user control do a > webRequest to the include file and return the content, as Kevin had > alluded > to earlier this week. Works beautifully and actually quicker than I > expected. However, I started to realize that I was running into a giant > brick wall comprised of all the supporting code that would be needed to > pass > any additional variables and/or post data into the webrequested form, > while > still retaining state and doing all the other stuff that a fusebox 3 > framework for .NET would need to do (nested circuits, etc.). > > Then I started thinking, which always gets me in trouble (not to > mention, > even more confused). > > Fusebox in itself, and from my impression -- so I could be wrong here -- > > is > an attempt to make a largely non-object oriented language act like an > object > oriented language. If you dissect a circuit, it is basically a class at > its > core. It has properties and methods and those methods are called in a > very > object oriented way. Granted, fusebox has given us many other benefits, > such > as nested circuits, always calling the same template, rapid development, > etc. > > .NET *IS* object oriented, from the ground up. > > So why are we trying to port a non-object oriented language's version of > > OOP > to a language or framework that already is? > > Being that I'm quite new to OOP, I could be totally off-target here, but > > why > couldn't we have a user control that grabs the fuseaction and any POST > or > additional GET data, and then based on the requested circuit and > fuseaction, > calls an appropriate method within the corresponding class? > > For example, say I click on a link that takes me to: > > http://www.workshed.com/index.aspx?fuseaction=users.add > > That could tell fusebox to call the add() method (fuse) within the user > class (circuit). > > Now granted, this brings up many, many questions, such as: > > 1) How realistic and/or time consuming would it be for a .NET developer > to > create a class for each circuit and compile it in with the fusebox user > control? (again, this is getting way outside my level of knowledge so I > could be way off base) Or is it possible to have the classes compiled > separately and then include/reference them in the user control at > runtime? > > 2) Is it possible to perform a dynamic call to a class in VB or C#? Sort > > of > like doing an Evaluate(fuseaction)? > > 3) Would it really be kludgey to not have the display files as part of > the > fusebox equation? How would web forms be dealt with in a model like > this? > > And there are many more questions as well, but I need lunch and my brain > hurts. > > Thoughts? Ideas? Am I just being silly an restating things that have > already > been said? Futile? > > -Bret > > > ==^================================================================ This email was sent to: [email protected] EASY UNSUBSCRIBE click here: http://topica.com/u/?bUrFMa.bV0Kx9 Or send an email to: [EMAIL PROTECTED] T O P I C A -- Register now to manage your mail! http://www.topica.com/partner/tag02/register ==^================================================================
