Hey Aaron, Sorry if my response isn't more Plum-related, but your questions kind of go beyond the scope of a single framework (although there are frameworks out there to help with some of your issues).
> We're working on a potential architecture for our CF apps moving forward > that is highly scalable and flexible, with as little redundant code as > possible. It's so cool that more and more CFers want architecture instead of scripts! > a centralized repository of CFCs (which are not dependent on any scopes, > especially Application and Session, that are tied to the CFAPPLICATION) > multiple applications/sites that use the same set of CFCs from the > centralized repository That definitely sounds like the right way to go. I've got a few (related) applications here that all use the same CFC-based API. > the majority of the CFCs will be used for data abstraction, mostly business > logic and calls to stored procedures (SQL Server 2000) If you're going to go to the level of writing an API to back your application(s), I'd recommend modelling your entities in CFCs as well. This not only abstracts your business logic, by esp. if you're working across applications, it can be very nice to have a strongly typed entity rather than a struct or loose collection of form fields that you just "make sure are always the same." > we want to be able to create multiple instances of CF (MX 7), and yet call > the central repository of CFCs directly (without exposing them as Web > Services, although now that I think of it this is probably a limitation of > CF and unrelated to PLUM?) That's going to be hard to do across different server instances without exposing things as Web Services. As an alternative, I'd recommend you define your application's API in terms of Service Facades - each application can then instantiate and make use of the same facade CFCs, which will insure they're using the same business logic, etc. There's a framework called Tartan (still relatively new) that is designed just for creating service layers, and I'm working with a few folks on a "sister" framework for Model-Glue called Service-Glue that exists just to make creating Service Oriented Architecture easier in CF. > the main problem I see with the out-of-the-box implementation of PLUM is > that CFCs are tied to each PLUM project, though the Application scope. >From what I remember of Plum, the CFCs that Plum uses are what I'd call stateless data services - they abstract SQL calls that manage persistence. That's an important service, but a service layer, esp. for the purposes you describe, needs to be able to do more than that - it needs to abstract your business logic as well as persistence. I'd probably do the following: 1. Either hand-write your service layer, use Tartan, or write your own service framework. (Tartan = www.tartanframework.org). Right now, I think Tartan is still being worked on, and while it's pretty cool, I can get stuff done faster by hand. 2. Learn to use CFCUnit to create unit tests for your service layer - that'll make sure that when you have bugs, you can quickly tell if they're a service issue or one of your application's issues. Automated testing is very, very powerful. (CFCUnit = www.cfcunit.org) 3. Use a presentation-layer framework like Model-Glue (shameless plug: www.model-glue.com), Mach-II (www.mach-ii.com), or Fusebox (www.fusebox.org) to write your applications. Does that help any? Sorry my advice didn't support Plum to a great extent :(. -Joe -- Get Glued! The Model-Glue ColdFusion Framework http://www.model-glue.com ********************************************************************** You can subscribe to and unsubscribe from lists, and you can change your subscriptions between normal and digest modes here: http://www.productivityenhancement.com/support/DiscussionListsForm.cfm **********************************************************************
