Single "context" bean cached in application scope

[Philip Hunt]

Hi,

I'd like to run an approach by this group, just to confirm that we're not doing something silly.  We've borrowed an approach that I saw used in an actual "Spring" application.

See attached coldspring.xml

We have a single "context" bean, which gets injected with references to numerous Service Layer CFCs (using default-autowire="byName").

That context bean then gets persisted into the CF application scope, using something like:
application.context = beanFactory.getBean('context');

This then allows us to do things like:
application.context.getUserService().getUserById(123);

Is this an approach that others are using?  Has it caused anyone any memory/performance issues?


Thanks,
Phil

[Brian Kotek]

Making a bean application context aware is actually an uncommon approach in Spring-based applications. Most people do not want their beans coupled to the application context unless there is some specific reason to do so.

I'm not sure what your "context" bean is, just a container for other beans that are autowired into it? If that's the case, what's the point of using it instead of just autowiring what you need directly into the beans? Personally I'd be leery of this type of "global container" that is used by (and thus coupled to) everything. Am I missing something?

Brian

[Joey]

I've got something similar, no memory or performance issues so far...
but I am looking for a better solution as this is a temp solution for
me personally.

- Joey

On Oct 13, 2:20 pm, Philip Hunt <hu...@dub3.com> wrote:
> Hi,
>
> I'd like to run an approach by this group, just to confirm that we're not
> doing something silly.  We've borrowed an approach that I saw used in an
> actual "Spring" application.
>
> See attached coldspring.xml
>
> We have a single "context" bean, which gets injected with references to
> numerous Service Layer CFCs (using default-autowire="byName").
>

> That *context* bean then gets persisted into the CF application scope, using
> something like:
> *application.context = beanFactory.getBean('context');*

>
> This then allows us to do things like:

> *application.context.getUserService().getUserById(123);*

>
> Is this an approach that others are using?  Has it caused anyone any
> memory/performance issues?
>
> Thanks,
> Phil
>

>  coldspring.xml
> 9KViewDownload

[Brian Kotek]

I doubt there would be any technical problem with doing it, I just don't see what sense it makes from a design perspective. Is there some specific reason that you prefer this instead of just autowiring the proper beans into the objects that need them? Isn't this just a ColdSpring-specific take on global variables, with all of the baggage that brings along with it?

[Mark Mandel]

I have to echo Brian on this one.

What is the use case for this anyway?  I'm failing to see what benefit you are gaining?

Mark

--
E: mark....@gmail.com
T: http://www.twitter.com/neurotic
W: www.compoundtheory.com

[Joey]

I see now what both Brian & Mark mean... makes sense.

For me I've only just started using coldspring, so I've basically
followed the doco on the Coldspring site... as for user case... I
think I won't it down on the back of a leaf... *lol* I'm pretty much
winging it at the moment.

For example...

I have a few cfcs that do some logic. ContentBean.cfc
I have a cfc with configy stuff (setting/getting datasource).
ConfigBean.cfc
And I have a gateway cfc for any queries. ContentGateway.cfc

Assuming then you kinda understand what my ConfigBean is doing...
getter & setter for datasource...

Coldspring.xml is something like...

<bean id="ConfigBean" class="dodgy.ConfigBean">
<constructor-arg name="datasource">
<value>${datasource}</value>
</constructor-arg>
</bean>

<bean id="ParentBean" abstract="true">
<property name="ConfigBean">
<ref bean="ConfigBean" />
</property>
</bean>

<bean id="ContentsGateway" parent="ParentBean"
class="dodgy.ContentsGateway" />

In my Gateway file I would have function like...

<cffunction name="getSomethingUseful" ...>
<cfquery name="usefulName" datasource="#getConfigBean().getDatasource
()#">
...
</cfquery>
</cffunction>

Is this wrong?

As for loading into application scope... is there a problem here? At
the moment I'm using fusebox framework, which also loads into
application scope. I had a reason for doing this, but can't remember
exactly why... I figure if there's no "big" issue with loading it in
application, then there's no reason why not to.

Hopefully I'm on the same track as Phil on this... and not off topic. :
$

- Joey

On Oct 13, 4:25 pm, Mark Mandel <mark.man...@gmail.com> wrote:
> I have to echo Brian on this one.
>
> What is the use case for this anyway?  I'm failing to see what benefit you
> are gaining?
>
> Mark
>
>
>
>
>
> On Tue, Oct 13, 2009 at 4:19 PM, Brian Kotek <brian...@gmail.com> wrote:
> > I doubt there would be any technical problem with doing it, I just don't
> > see what sense it makes from a design perspective. Is there some specific
> > reason that you prefer this instead of just autowiring the proper beans into
> > the objects that need them? Isn't this just a ColdSpring-specific take on
> > global variables, with all of the baggage that brings along with it?
>

> E: mark.man...@gmail.com

[Kevin Pepperman]

Joey- Fusebox does load into the application scope, but not directly. It uses Application[variables.appKey] ( ie: getApplication() )which is unique to the app instance.

For Fusebox/FuseNg , especially if you are using the NOXML flavor, have a look at this "Add simple beanfactory support" proposal by Sean Corfield.

http://jira.fuseboxframework.org/browse/FBI-10 (Please Ignore the incredible amount of spam.)


It is very simple to add the code to the FB core yourself. It is supposed to be added shortly by Adam. Sean provides the working code in Jira as well.

This adds the methods setBeanFactory(), getBeanFactory() and getBean() to the myFusebox object which handles the caching of the Coldspring Factory and the individual beans as they are called.

This is an alternative to using your own application scoped factory, or the more verbose Lexicon parsed methods myFusebox.getApplicationData().coldspringfactory.getBean(beanName="myBean").


You just initialize ColdSpring in Application.cfc's onFuseboxApplicationStart() , then add the coldspringfactory with myFusebox.setBeanFactory(coldspringfactory).

Then in your controller you can just use myFusebox.getBean("myBean")


I like this method, and have used it in my last several apps. It makes sense to allow the framework to manage the Factory, and since myFuseBox is already right there in all requests, it just works.


/Kevin