Moving Things Around in Our Service Layer
Last week, I showed you how I had setup my register method in my project. After a couple of comments, I realized I had tied my service layer too tightly with my MVC framework (ColdBox), by passing in the entire event object, rather than just the data that I needed. Today, I explore a different way of doing things, while also making a couple of little changes to the way the handlers are setup.
Autowiring Beans to Handlers
Last night, I was reading up on part 8C of Jason Dean's Coldbox series and thought this could be a very small change that'd save me alot of trouble in the long run. I won't repeat his post, because that'd be cheating, and I ain't no cheater, no sirree! The essence of it was that, rather than calling getPlugin() on the ioc framework every other method to get a reference to your beans, you could ask Coldbox to provide them for you automatically.
Before Autowiring
Get a reference to the userService bean.
--->
<cfset var userService = getPlugin( "ioc" ).getBean( "userService" ) />
<!---
Call the service layer's method.
--->
<cfset userService.doSomething() />
After Autowiring
We already have our reference, so we can call the method directly.
--->
<cfset variables.userService.doSomething() />
Getting Coldbox to do this is rather simple. I'll let you run over to Jason's post to see how that's done, and I'll wait for you here.
Passing Data to Our Service Layer
In the previous iteration of this series, I had sent the data from the handler to the service layer by passing in the entire event object. From the comments, I could see that this was a big no-no, and I think I finally see why. By passing in the event object, we are coupling the service layer tightly with the framework in use. This means that, if for some reason in the future I need to change my framework to something else, I'd have to change my service layers as well. This is contrary to the spirit of OOP, and I won't stand for it!
The way I see it now, using Coldbox's getCollection() method to retrieve all the keys in the request collection will allow us to pass in the request variables to the service layer without coupling it to the framework. Of course, the request collection doesn't only hold the form variables, but we'll leave the sorting out to our service object.
The New userService Service Object
<cfargument name="username" type="string" required="true" />
<cfargument name="password" type="string" required="true" />
<cfargument name="password_confirm" type="string" required="true" />
<cfargument name="email" type="string" required="true" />
<!---
The rest of the code stays the same. However, rather than
calling event.getValue() to access our form variables,
which is Coldbox-specific, we can call them through
our arguments scope.
--->
</cffunction>
Having the arguments defined in the method's header allows us to simply pass in a call to Coldbox's getCollection() method. Sure, there'll be some junk in there our method won't need, but it beats having to hard-code our method call.
Passing Our Values to the Service Object
argumentCollection = arguments.event.getCollection()
) />
And that's all for today! I feel that I'm getting closer to my goal of understanding how all of this sticks together, and hopefully the experts out there do too! However, this is a learning process, so if you feel there's something off with my reasoning, thanks in advance for letting me know!
Thanks for the thumbs up. I honestly don't even remember where I picked the argumentCollection bit up. I had originally done it by passing the entire struct, but felt the service layer's API became too open that way. This way, it's clear what the method needs, and it brings new possibilities to the table (automatic code documentation, anyone? :P).