Thinking About Data Gateways, Collections, And Raising Exceptions

"Any data access request for a single object based on ID (ex. Read, Update, Delete) should raise a "DataAccessException" if the target record cannot be found."

I really have to disagree. To me, a DataAccessException would indicate that there's a problem with the query itself- incorrect syntax, database connection error, something like that. As far as the data layer is concerned, if it successfully ran the query, it's job was successful.

I could possibly see doing this on an Update, but only if the operation *had* to be an update, i.e. You couldn't set up the data layer to do an Insert of there was no record to Update.

As far as Reads that are supposed to return a single object, I still wouldn't throw an exception. In C#, I'd return a null. Since CF still (I assume) doesn't have the concept of a null, I'd probably return an empty object.

I get what you're saying about transactions that span data objects, but I think you're putting your "control mechanism" in the wrong layer. If you have a transaction defined in a layer that sits just above the data layer, then that layer should be responsible for determining whether to continue with the transaction after an operation, or whether to roll back.

"But, handling NULL objects in ColdFusion feels like a bit of a burden."

Yeah- it did to me, too. To the point where I started building null.cfc and then realizing that I was overreacting. :)

"I'm just saying that an exception could make it easier since the transactional layer doesn't have to check *each* data access result - rather, it simply has to "try" all of them and if any of them fail, they all fail."

True. However, when you start building your data layer with the idea of making known behavior in your service layer easier, you start limiting your data layer. In this case, if you wanted to check to see if a certain record is present, you'd have to use a Try/Catch and either have an empty Catch or have your Try/Catch handle branching your code. Something like (and this is the first time I've tried the code tag):

try
{
dataLayer.Get(object);
return true;
}
catch
{
return false;
}

Whereas, if your data layer just retrieves whatever data meets the criteria its given, you have the much more manageable

return dataLayer.Get(object) == null;

All of your business logic is in the proper layer. Your data layer is like your dog. Just fetch the stick.

@Ben,
Another thing to think about is to break down your service layer methods into methods that are used to serve data to the controller/views and those that are used to facilitate business logic.

Taking your delete blog example for a moment. In your service layer you would have deleteBlog service method and deleteAllComments service methods.

Each one would handle security access before delegating to the gateway. This is where I personally would put a cfthrow call.

<cfcomponent name="blogService">
 
<cffunction name="init">
	<cfset variables.securityService = arguments.securityService>
	<cfset variables.blogGateway = variables.blogGateway>
	<cfset variables.commentsGateway = variables.commentsGateway>
	<cfreturn this>
</cffunction>
 
<cffunction name="deleteBlog">
	<cfargument name="blogId">
	 
	<cfset var message = "Unable to delete">
 
	<cfif NOT variables.securityservice.isAllowed("deleteBlog">
		<cfthrow message="Delete blog permission denied">
	<cfelseif deleteAllComments(arguments.blogId)>
		<cfif variables.blogGateway.deleteBlog(arguments.blogId)>
			<cfset message = "Blog deleted">
		</cfif>
	</cfif>
	 
	<cfreturn message>
</cffunction>
 
 
<cffunction name="deleteAllComments" access="private">
	<cfargument name="blogId">
	 
	<cfset var deleteSuccess = false>
 
	<cfif NOT variables.securityservice.isAllowed("deleteComments">
		<cfthrow message="Delete blog comments permission denied">
	<cfelse>
		<cfset deleteSuccess = variables.commentsGateway.deleteAllComments(arguments.blogId)>
	</cfif>
	 
	<cfreturn message>
</cffunction>
 
</cfcomponent>

Typo, the last function should return the deleteSuccess variable.

Really there are two aspects to security for mvc.

#1 access which is concerned with displaying controllers etc
#2 function which is concerned with running service methods.

I put the access aspect in the controller layer (which is what you describe).

How I build my app is something like this.

My first step in the controller request logic is to check if the user is authorized to get at a view. I do this globally using the setupRequest controller method defined by FW/1 in application.cfc (which is basically a version of onRequest).

Then if the user can use a controller/view I selectively turn on/off elements to display from the controller.

Finally when a service layer method is called I confirm function permission.

That way I have double protection.

#1 At the controller I am confirming if a user can see a particular view and what parts of it eg "Delete Comment" button

#2 Then if the delete comment function is called I am confirming they can run the Function from within the service layer.

Both ways though I am running through the same securityService component which handles the session object.

For simplicity sake I actually proxy the service layer functions I need out at the controller layer as udfs.

@Ben,
Just re-read your comment and yes that's exactly how I deal with it. The only modification is again I call the security service from the controller to do the check of session variable as opposed to directly referencing it in the controller code.

@Ben,
Yes it is a bit more repetitive to do the call in the controller than the view. But remember like you said, the individual controller component methods are only part of the overall controller system.

FW/1 for example defines a before method which you can define repetitive actions in. So you could end up with a controller file that looks like this.

<cfcomponent hint="Blog Controller">
 
	<cffunction name="before">
		<cfargument name="rc" required="true" type="struct">
		<!--- Before any controller method is run first check is the user an admin --->
		<cfset rc.isAdmin = services.securityService.isAdmin()>
	</cffunction>
 
	<cffunction name="article">
		<!--- snip--->
	</cffunction>
	 
	<cffunction name="addComment">
		<!--- snip--->
	</cffunction>
 
</cfcomponent>

Taking this further if you want to just do this check at every page request you can leverage onRequestStart (FW/1 defines a custom onRequestStart type method called "setupRequest" in the application.cfc file).

Finally its important to remember that one of the benefits of having a controller is that you can switch out the default view with a different one for different user types. This is particularly useful if the layout is significantly different.

In FW/1 for example you could have two views for an article. One for normal users which would be defined in article.cfm and an administrator specific view defined as articleAdmin.cfm. Both would pull the same data and have the same url, but the controller would switch between the two like this.

<cfcomponent hint="Blog Controller">
 
	<cffunction name="before">
		<cfargument name="rc" required="true" type="struct">
		<!--- Before any controller method is run first check is the user an admin --->
		<cfset rc.isAdmin = services.securityService.isAdmin()>
	</cffunction>
 
	<cffunction name="article">
		<!--- snip--->
		<cfset blogArticle = services.blogService.getArticle(arguments.blogId)>
 
		<cfif rc.isAdmin>
			<!--- Override the default for if the user is an admin --->
			<cfset setView( 'blog.articleAdmin' )
		</cfif>
	</cffunction>
	 
	<cffunction name="addComment">
		<!--- snip--->
	</cffunction>
 
</cfcomponent>

<Strong>General Thoughts
Thanks Ben that is an interesting idea to throw an exception when the result set is not what the method intended. It make me think that it is a good thing on the update or delete functions...

But the retrieveByKey I have mixed feelings on. On the one hand when I'm doing a save in my service layer, retrieveByKey throwing an error would be good for the transaction, but when my service is just trying to look up if it exists, then it would be a unneeded exception.

*debating in head* - I'm really starting to think this may be a good idea, especially since we also throw exceptions when "validation" occurs.

<Strong>Another Gateway idea
And Not to throw another idea into the mix, but myself and my-coworkers just adopted a slight change to what seems to be normal in CF community.

Our DAO (data gateways) functions only ever return a query(retrieve,etc) or void (insert/update/delete).

And then within our Service layer we'll convert it to an DTO or an array/structure of DTOs depending on how many rows are expected.

I know it doesn't remove the dependency on the DTO from the DAO, but it does remove the need for the DAO to know how to create a DTO.

Security Layer
I haven't used FW/1 yet, so I don't know if this exists. But I am a heavy user of ColdBox and it has introduced AOP into the framework, which allows you to remove the Security out of your services based on design, of course this takes even more design upfront before just coding. I will say I'm an expert, so I'll refer anyone reading to the ColdBox site http://wiki.coldbox.org/wiki/WireBox-AOP.cfm

I understand your head hurts. I've been doing some sort of MVC for almost 10 years now (within CF), and until lately with the frameworks, ColdBox and FW/1, I struggled with why I was doing it that way. Now I see the power and I also see my applications getting more "complicated" or complete compared to in the past. I truly believe that is the case because of the frameworks adding value to my applications.

Great blog entry, Ben. It's nice to know that I'm not the only one whose head hurts after thinking so much.

Ben,
Dealing with Queries in my mind is just like an Array of DTOs! There are just some extra advantages with actually using a DTO rather than a Query. That is the reason I use both, just a different layers of the OO/MVC framework.