Factory example using our Reactor Gateway Factory
ColdFusion
One of a number of techniques we employ to cut down processing on our Reactor applications is to treat each gateway object that is created as a singleton and only one instance of each gateway exists per application intance. An easy way to acheive this is by using a factory to produce the Reactor Gateway objects when needed, and for that matter only one instance of the factory itself is ever created. Basically when you request a "Foo" gateway from our factory, our factory object first checks to see if the Foo gateway exists yet in the application scope. If it doesn't, it is then created. It then returns the application scoped Foo Gateway.
Here is our approach.
First, we will create our ReactorGatewayFactory object. It consists of only two methods:
Then in our methods that get intialized on application load, after we instantiate the Reactor Factory into the application scope as application.ReactorFactory, we put that Gateway Factory in the Application scope like this:
Now in our code when we need access to the Foo gateway we simplay call:
It should be noted that this techinque is by no means limited to use by the Reactor gateway factory, and was simply used to illustrate an example. We take the same type of approach with a Facade factory, standard Data Gateway Factory, and others.
- init() which accepts the Reactor Factory as an argument
- createGateway() which accepts the name of the Object which you wish to create a Gateway for
Brian Kotek said:
A couple of things here. First, unless I'm mistaken, Reactor doesn't keep regenerating the Gateway every time you ask for it. Once it is created, it just returns that instance (assuming that the factory itself is in a persistent scope of course). I'd need to confirm this but I'm fairly sure this is the case.
Second, I think the idea of the "reactorGatewayFactory" is redundant. In other words, I'm not clear on what you're gaining by this. If you need a gateway, you can just get it from your application-scoped reference to the Reactor factory:
<cfset FooGateway = application.Reactor.createGateway("Foo") />
Lastly, you might look at using ColdSpring to inject the gateway into your CFC at application startup. This would render the previous two comments moot. You can do away with not only the gatewayFactory, but also the code that is calling the gateway factory. You can replace this with constructor- or setter-injected gateways by using ColdSpring's factory method support.
Even for things like Records that generally shouldn't be kept in the application scope, you can use ColdSpring to inject a reference to the Reactor factory itself into any CFCs that need it. Let me know what you think or if I'm missing something. Thanks.
Second, I think the idea of the "reactorGatewayFactory" is redundant. In other words, I'm not clear on what you're gaining by this. If you need a gateway, you can just get it from your application-scoped reference to the Reactor factory:
<cfset FooGateway = application.Reactor.createGateway("Foo") />
Lastly, you might look at using ColdSpring to inject the gateway into your CFC at application startup. This would render the previous two comments moot. You can do away with not only the gatewayFactory, but also the code that is calling the gateway factory. You can replace this with constructor- or setter-injected gateways by using ColdSpring's factory method support.
Even for things like Records that generally shouldn't be kept in the application scope, you can use ColdSpring to inject a reference to the Reactor factory itself into any CFCs that need it. Let me know what you think or if I'm missing something. Thanks.
Brian Kotek said:
Yup just confirming that in production mode, Reactor will attempt to use a cached version of any DAO, Gateway, Metadata, or Validator instances before it creates one. And when it does create one, it only does it once and then places it in the internal cache.
Dave Shuck said:
Brian, that is very interesting and it makes a lot of sense. I first started using this method around last January and at the time I am fairly certain that it didn't work that way (although I am wondering now!). I posted this idea on the reactor list at that time and it seemed to float as a sound idea.
About ColdSpring, I know that I desperately need to delve into it, but I simply haven't. I sat in on Chris' session at CFUnited and was blown away. Hopefully one of these days I will catch up to the rest of you guys... but I doubt it!
About ColdSpring, I know that I desperately need to delve into it, but I simply haven't. I sat in on Chris' session at CFUnited and was blown away. Hopefully one of these days I will catch up to the rest of you guys... but I doubt it!
Brian Kotek said:
Don't sell yourself short Dave, ColdSpring is really not difficult at all. I have a blog entry on it and I also just wrote one for Builder.com (though I'm fighting with them right now to fix the XML formatting in the code example). Perhaps your questions are a good incentive to write about it some more. ;-)
Peter Bell said:
Hi Dave,
This was the way I used to do things also, but can't you just ask ColdSpring to take care of this now and to handle injecting the Gateway into your service objects (or whatever else needs them)? I have't played with that with Reactor acting as the factory, but I thought there was information out there on how to do this.
Benefit is that then your code doesn't need to know about your factory - it just has all of the beans it depends on injected in . . .
I'm pretty sure this is what MG does.
This was the way I used to do things also, but can't you just ask ColdSpring to take care of this now and to handle injecting the Gateway into your service objects (or whatever else needs them)? I have't played with that with Reactor acting as the factory, but I thought there was information out there on how to do this.
Benefit is that then your code doesn't need to know about your factory - it just has all of the beans it depends on injected in . . .
I'm pretty sure this is what MG does.
Loading....