Thanks everyone that came to my talk "MVC With and Without a Framework" at CF Summit East yesterday! Code and slides from the preso are available on GitHub. Enjoy. https://github.com/nolanerck/mvc-with-and-without-a-framework

Was it recorded?

Hi Nolan, thanks for sharing. One thing I've learned from this channel is most ColdFusion shops use OOP and MVC over procedural or event-driven. I use MVC too, but without frameworks such as FW/1 or ColdBox. Instead I use the Application.cfc to control the flow of requests and use rewrite patterns that route to individual components. I've also traditionally leverage SQL with procedures as the model layer and call them with CFstoredproc. But apparently I am in the minority. I'll study your examples, I'm certainly open to know how most folks do this.

@Bill Nourse it sounds like your setup is pretty close to what FW1 is already doing. Curious what you're getting from your homegrown setup that FW1 doesn't provide.

Hey @nolanerck, Thanks for asking. Here is the first reason 😉 <!--- index.cfm is ignored and should be empty ---> The second reason is routes. Modern patterns using go, ruby, node, etc use friendly URLs. But with FW/1 you get this... ?action=section.item&name=value... (remember Fusebox?) I've also seen "index.cfm" exposed on so-called "enterprise" applications... I really don't understand that. Yes, I realize you can make the above URL friendly by using rewrite rules in your web server, but it requires an additional layer. And finally, I prefer to use as few dependencies as possible, I like to keep it pure and simple. Both Lucee and ColdFusion are great frameworks right out of the box, IMHO you really don't need another framework. With sensible naming conventions, separation of concerns, and an organized file structure, an enterprise app may not need a third-party framework. Cheers, Bill

1. There is a setting in FW1 so you can get the SEO friendly URLs you're mentioning. So ?action=section.item?name=value becomes /section/item/name/value. (ColdBox can do the same thing too...in both frameworks this is a very simple config option that just needs to be turned on.) 2. I don't see why having an empty index.cfm file is a big deal. Many larger app type systems have pretty minimal index files as everything happens internally elsewhere. Mura and Masa, for example, have just 1 line of code in the index.cfm file. 3. index.cfm can be hidden from URLs in any CF app. Wether you're using a framework or not is irrelevant. It's just a setting in the web server config to hide those files and then poof...it's hidden. In modern setups this can be done in a config file that's loaded just like any other source code file. Apache has its .conf files, IIS has web.config and Ngnx has its config files. They can all be stored in GitHub just like any other file in the app. Frameworks are not required to do this. Nor are frameworks somehow prohibited from doing this. 4. Lucee and ColdFusion are not frameworks. 😉 5. While I agree that not every app needs a full blown framework, all due respect, I think you'd get more value here by asking for support from the community and using tried and true tooling, rather than rolling your own solution. My 2 cents.

Hmm, did I hit a nerve? That was certainly not intentional. I've read that Michael Offner does think highly of frameworks such as FW/1 and Coldbox. But he also mentioned that the Application.cfc is "like a mini framework". I don't mean to offend anyone here, I agree with you and Michael that these frameworks are solid and "tried and true" as you say, and I do understand how they work. My point is they are not always necessary. Instead, I believe we should "consider" and "explore" other methods and patterns, and keep an open mind. The standard MVC OOP pattern is by far the most preferred, and it works well. But if someone (like me) thinks outside the box (no offense to Ortus), please do not take it as criticism. Take it as an alternative opinion.

Didn't strike a nerve. But all due respect, you do seem to be misinformed about some of the tooling that's available. (ColdBox also has an "empty" index.cfm file, FYI.)

Hi Nolan, I may be "misinformed" as you say, but you really haven't sold me on why I should bother. However... Your comment did motivate me to do some research... This guy (@pegarm David Byers) is awesome. I read his three part essay on learning ColdBox, and related to every single word he wrote. Here is the third part of his series... https://coldfusion.adobe.com/2020/10/framework-training-part-3-learning-develop-using-coldbox-framework/ I love his analogy of frameworks as "sandblasting a soup cracker". I literally laughed at that one. He concluded by saying he would use Coldbox for future projects, but not 100% of them. Seems like practical advice to me. So, with David's advice, I think I'll give Coldbox a shot.

Thanks for these examples and slide show. I've been looking for an example of MVC w/o use of a FW. I've built a couple small apps using FW/1 and I felt it actually slowed me down (but I was also using ORM, so that may be to blame). One thing I don't jive with in the MVC pattern is putting business logic in the same components as query-functions. It seems like keeping a one-to-one ratio with the db tables to cfcs that work with them, and nothing else going in in there, is a good seperation strategy. And let the middle layer between those and the views be where the business logic and data flow happens.

Hi brendan, Ever since I was titled as misinformed by Nolan, I've been doing a lot of research on the subject. In a nutshell an MVC is a model that accesses the data, a view that paints it to the screen, and a controller that glues it all together. Simple enough, but does require the engineer to think through how to organize the code. Which is the whole purpose of a framework, to do the organizing thinking for you... along with other tools such as testing. But do you really need a framework? And is that the only way to organize your code? Absolutely not, you can write your own patterns just as the framework authors did. But there is the catch 22. In order to build a better pattern, you "should" understand the tried and true patterns first, they were written by some very smart people. I admit Nolan was right about that. In regards to what you were asking, thinking in terms of separation is a good thing IMHO, I personally like having smaller components. My only advice is to think in terms of "objects" rather than database "tables" if that makes sense. As an object could be a combination of multiple tables and other various references. Think of an object as a structure of data elements such as values, arrays, query results... all returned in one call.