Coldfusion architecture and code layout

Posted At : August 3, 2006 10:32 AM | Posted By : Mark
Related Categories: ColdFusion

I have not seen any concrete examples of how people layout their CF applications and subversion repositories so I thought I'd explain how we do it at RedBalloon and hope it's useful for someone. Our main goals are are Simplicity, Reuse of code and Security.

The following are the base level components we use in each site and mirror the structure we have in subversion.

For RedBalloon we have:

  • core - Non web accessible, mapped as /core which contains generic and reusable functionality - i.e. function libraries, well encapsulated code that is relevant for any site etc.
  • rbd-core - Non web accessible, mapped as /rbd-core and contains CFC which encapsulate specific RedBalloon business logic as well as Custom Tags and Includes.
  • rbd - Web accessible, front of the website. Mostly simple cfm pages which call the rbd-core cfcs for anything complex.
  • rbd-suppliers - Web accessible area for Suppliers to login. Again simple cfm pages which call the rbd-core cfcs to actually do anything.
  • rbd-api - CSV, RSS and SOAP access

For GoDo we have a similar layout:

  • core - common library shared with redballoon - non web accessible
  • godo-core - business logic - non web accessible
  • godo - Consumer website - web accessible
  • godo-suppliers - Supplier area - web accessible
  • godo-api - CSV, RSS and SOAP access - web accessible

This is very similar to how FarCry is laid out, and where the inspiration and naming came from, the only difference being that we have a core, which contains common functionality, and is the kind of code you would include in every project you ever worked on.

Note: If anyone is thinking of implementing this or similar I would suggest calling core -> common-core because when we are talking in the office we often end up referring to it as core-core to be sure, to be sure!

Comments (2) | Print | del.icio.us | Linking Blogs | 1369 Views
Comments
[Add Comment]
Ben Davies's Gravatar Hi Mark,

This was interesting. I'm looking for similiar sorts of information because I'm preparing for a new project and would like to get fundamental things right.

We actually have about 9 different folders at the moment, some of which corresponded to different CF instances (like main, reporting, scheduling), and some of which are common (like business logic and libraries). I'm seriously thinking of simplifying this next time round, and your divisions look reasonable.

One question though: Assuming you have all your subversion directories in the same layout, is there any inconvenience when releasing projects that affect a few files in more than one folder? This might seem like a funny question but my background is in VSS, so that might explain it.

Cheers
# Posted By Ben Davies | 8/3/06 12:46 PM
Mark's Gravatar Hi Ben,

We have the subversion repositories as mentioned above and in each one we have the conventional trunk, tags, and branches folders.

So we have:
www.example.com/svn/core/trunk
www.example.com/svn/core/branches/1.0.x
www.example.com/svn/core/tags/1.0.0
www.example.com/svn/core/tags/1.0.1
www.example.com/svn/core/tags/1.1.0

So when we check out the code we would check out the relevant part of the repository. i.e. if we want version 1.0.0 we would checkout www.example.com/svn/core/tags/1.0.0 as 'core' on the relevant server.

So when there is a change across multiple areas of the site - i.e. core, rbd-core, rbd then we need to update all of the relevant areas.

So in answer to your question, there is some inconvenience, but it's the best compromise we've come up with yet.

To mitigate this we typically keep the release tag numbers in sync (except for core) for all RBD related parts, and similarly for all GoDo related parts. It's not a perfect solution but it works well. Love to hear ideas how it can be done better!

Cheers,
Mark
# Posted By Mark | 8/3/06 1:31 PM
[Add Comment]