Thanks for writing this post. I am currently trying to implement something similar at work, and I was having a tough time visualizing how exactly all of the objects should be laid out. This was a nice reference for me since I have only begun taking the plunge into OOP world.

It might still be a good idea to still keep all of your separate UserDAO, CompanyDAO etc, but to have them all extend your TransferDAO. This way they inherit all of the base TransferDAO functionality, but also allow you to add custom functionality specific to that object.

For example, your CompanyDAO may have a function delete() that might do some extra work first before asking the parent TransferDAO to delete the company record.

Another thought; you might like to rename your TransferDAO to BaseDAO to keep it even more generic.

Yes! To check for the userid works great! I was first thinking of some kind of RecordCount solution, but this is better.

To avoid having transfer methods everywhere I did a generic TransferDAO that wraps the transfer functions I am currently using, instead of having UserDAO, CompanyDAO etc. I also try to have generic but descriptive names for the methods such as list, delete, create and of course readByPropertyMap (maybe quite generic anyway). Now I have only one class to deal with for Transfer things, and generic data access metodh names, that I don´t have to change if I change ORM.

Searching on both userEmail and userPassword sounds good to me.

I understand that if Transfer can’t find a matching record then it returns an empty User object. You might like to check the userId on the object returned from the userDAO to see if the user was found.

For example, in the SecurityService object:

<cffunction name="getAuthenticatedUser" output="false">
<cfargument name="username" type="string" required="true">
<cfargument name="password" type="string" required="true">
<cfset var user = variables.userDAO.readByUsernameAndPassword(arguments.username,arguments.password)>
<cfif user.getUserId() gt 0>
<cfreturn user>
<cfelse>
<cfreturn "">
</cfif>
</cffunction>

First I created a UserDAO that gets the user by transfers readByPropertyMap.

I put the UserDAO and the SecurityService in the Appplication.cfc OnApplicationStart method as singeltons (application scope).

In the SecurityService I pass both the username (in my case e-mail) and password to the UserDAO (therefore the readByPropertyMap). I don´t know if it´s best to search only in the user field or both the user and password field, It felt better to restrict the query as much as possible.

Before my modification of the SecurityService I tested it with your set up, and found that if you don´t fill in anything in the login fields you still get validated, and a user object is created (Probably empty. Dump just shows an empty transfer object). So I added LEN(arguments.password) to check the length in the SecurityService and don´t return a user object if it has no length. Maybe a Transfer thing, how it creates objects.

Because I use Transfer and no framework I think I don´t have the need for dependency injection in this simple case.

Great example anyway!