Yeah, in general, I prefer to keep my gateways and DAO's separate. So DAO's operate on a single instance of a business entity, and gateways are basically collections of SELECT statements that don't return objects. Most of the time they return recordsets/queries, but some return number or strings (like a getXXXCount style method).

Regarding services/managers, it's mostly personal preference. I happen to generate my managers automatically, so having the services separate (which are largely hand-written) makes future regeneration a lot easier.

In the great scheme of things, the specifics don't matter too much. As long as you're encapsulating all the needed functionality in a logical and consistent way, it's hard to really be "wrong".

Thanks for that – I'm interested to see how differnt people organise their CFCs.

I'm actually Barney, not Barry, but it's all good. I use a single mapping (/com/domain) that points to the ${approot}/cfcs/com/domain directory, and then branch from there. I usually put my entity objects in a separate package (like com.domain.data), and then put my non-entity objects in other packages. By entity objects, I mean all the per-entity stuff, so BOs, DAOs, managers, and some gateways and services.

Just for reference, I also have a /ct/domain mapping that points to ${approot}/tags for all my custom tags. So every non-trivial app I build uses two CF mappings, and no external custom tags.

This actually looks very similar to how I'm currently setting up my applications. So either I now feel like I'm on the right track, or we're both crazy ;o)

I'd be also interested to know how you setup your CFCs in terms of directories, and how you decided to organise your CFC roots – did you place them all in a directory at the root of your application, or set up a mapping etc?

I've refactored my current app (my website v2.0) about 3/4 times trying to work out what the best/favourite way to structure CFCs was, and I still can't decide. :o/

Just to be clear, you have several read() methods in your DAO that take different parameters that can uniquely identify an entity? I have to say I never considered doing it that way, rather having my DAOs be exclusively primary key based, and having lookup methods (in my gateway) that will translate unique identifier X into the corresponding primary key, which is then use for the DAO. It's also a lot easier to generate my DAOs automatically that way, though if you have the unique keys tagged in your database, I suppose you could generate the other read() methods as well. Like I said in my post, the primary impetus for the DAOs was to never again write entity persistance queries, so autogeneratability is of great import.

For the BO (bean) population stuff, I use a manager (or factory) for this. So I call getUserById() or whatever, which instantiates a user BO, sets the id field on it, and passes it to the DAO to populate (a SELECT query and a bunch of CFSETs). Then the manager returns it to whomever requested it. My DAOs are implementation details of the managers; there's no other way to get a reference to a DAO. Managers handle creation and persistance operations for entities, and that's all they do. They happen to use DAOs to do it. Makes sense to me, but I've been called crazy before. ;)

Good stuff.

It's interesting to see the differences between FB3, FB4.1, and MG/M2. Since the controller/listener classes in the latter are CFCs, there's many choices in how to use CFCs for the services, logic, and persistence layers. It's the same thing only different, if you get my meaning. ;)

In the past, I've tended to use a simple composite relationship between DAO/Gateway and the controller… in the controller just doing a cfset thisDAO = createObject(…). For simple things it's still a fine way to go. However I've also been experimenting with more elegant ways to expose the model to the controller, either with something like ColdSpring or ChiliBeans (which is built in to ModelGlue) to generate collection instances that hold the DAO/GW instances. I find myself using collection objects a LOT.

The thing that's pestering me the most at this point is the overlap of code between some of the read methods in my DAOs (by email, by ID, by email+password) which makes several queries to maintain. I've also been looking at breaking code into several controllers, which can create a code duplication problem (in this case, a good time for inheritance).

So I appreciate you putting this out here and giving us a point around which to discuss these issues. :)

One question though… I've read a couple things lately that indicate some people are returning populated user beans from a userDAO.read() method. Personally I think it's messy. Personally I tend to think that calling a UserService, which executes userDAO.read() and then creates a bean and populates it is cleaner and more flexible. Granted there's no "rules" on this sort of implementation-specific situation, but what's your feeling on the issue?

For my part, right now I have a controller that calls a DAO method it gets from a service and passes that record to it's own private method to generate a user bean from the query. It's not the best and will change, but I like it better than blending factories and CRUD in a DAO.

First and foremost, it's what the app's already written with, and none of those other frameworks bring enough to the table to make it worth the switch. I haven't counted in a while, but it's probably about 50 circuits, ranging between 8-10 and 40-50 fuseactions in each one.

But even if I were writing from scratch, I'd probably still stick with FB3, because the app is so complex but the UI isn't. Even FB4 (which I helped write) is complex to use for simple tasks, and a thin UI layer doesn't warrant that complexity. If you have a UI that requires a lot of page assembly (i.e. complex layouts/portals), then FB4 is a much better choice, but I don't have that need in this particular app.

It's worth mentioning that when I say "FB3″, I don't really mean your standard run-of-the-mill FB3. I've made a couple tweaks to the core (minor ones, like requiring fbx_Switch in every circuit), but most important is the 'do' UDF, which emulates FB4's DO verb, but without the performance benefits.