Dave, I'd have to disagree with you here. ASP.NET's code-behind is sweet feature. Yes, it helps desktop developers transition but the things you can do in a code-behind are VERY nice, which CF can't do.
For instance: - The different steps of a page loading you have access over (much more than App.cfc gives you) - Controlling page elements (with runat="server") from the code-behind at the different parts of the page loading - 100% complete separation of code and visuals (no instantiation of objects, etc at the top of the page...they are already there) Mind you, I'm not putting one against the other (we saw a couple months back where that can go). I'm merely stating the code-behind is a nice feature. Especially when you put 1 .cs to multiple .aspx's. You can create multiple cfcs or custom tags but you don't get the same level of granularity or control over a loaded page. BTW, I still love CF. :-) On 11/29/06, Dave Watts <[EMAIL PROTECTED]> wrote: > > > What I am wondering is what some of those who are experienced > > with ColdFusion and OOP think about using the code-behind > > technique for the controller layer in an MVC application? > > Before I respond to this, I should qualify my ASP.NET experience; I > wouldn't > call myself an ASP.NET expert. I am, at best, a mediocre ASP.NETdeveloper. > > That said, when you develop an application in ASP.NET using Visual > Studio.NET, the programming model or framework that you're given relies on > postback forms to provide an illusion that web applications work like > desktop applications do. You need code-behind classes because you spend so > much time on a single screen, even though that "screen" might correspond > to > several steps within your application, which are wired together via the > postback form. Before ASP.NET, "classic" ASP didn't have code-behind - you > either wrote external COM objects and invoked them from ASP, or you wrote > your code inline. > > Without that model, code-behind classes by themselves don't bring much to > the table. You could just as easily write plain ol' components, and invoke > them however you like, from your CF pages, without a one-to-one > correspondence between pages and components. After all, your "form > validation and such" is stuff that would likely be common across your > application (or across multiple applications) rather than being specific > to > a page. > > Personally, I prefer the simpler model of CF development; this is probably > because I didn't have years of desktop application development under my > belt > before learning web development. > > Dave Watts, CTO, Fig Leaf Software > http://www.figleaf.com/ > > Fig Leaf Software provides the highest caliber vendor-authorized > instruction at our training centers in Washington DC, Atlanta, > Chicago, Baltimore, Northern Virginia, or on-site at your location. > Visit http://training.figleaf.com/ for more information! > > ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~| Introducing the Fusion Authority Quarterly Update. 80 pages of hard-hitting, up-to-date ColdFusion information by your peers, delivered to your door four times a year. http://www.fusionauthority.com/quarterly Archive: http://www.houseoffusion.com/groups/CF-Talk/message.cfm/messageid:262166 Subscription: http://www.houseoffusion.com/groups/CF-Talk/subscribe.cfm Unsubscribe: http://www.houseoffusion.com/cf_lists/unsubscribe.cfm?user=89.70.4
