The beans scope is preferred for 2 reasons:
Annotation/Documentation
The beans referenced in a particular controller using the beans
reference would all the documented in a single place at the controller
definition. This would make it easier at a glance to understand which
beans are used in which controllers.
MG Caching
Naturally, the beans are injected into the controller and will live
inside of the controller state for the lifetime of the controller.
Summary
The documentation part is important and I do prefer it to be this way
when I write my code. However, a continuous integration scenario may
rate higher on the priority scale for you.
The caching part is negligible since ColdSpring will be serving
references to your beans from a cached state. Thus, there is likely no
performance advantage worth speaking about.
Please share your findings
DW
Brian G wrote:
Jared - thanks for the thoughts; I looked at getBean() in MG/CS - it
doesn't appear MG caches it and the CS getBean() method looks to see
if a bean exists in the local factory and if not it passes the request
to the parent. So, I believe using setParent() on the internal MG
factory will indeed make subsequent calls to the beanfactory access
beans from a newly-updated beanfactory from setParent().
Dan, here's the questions I'm looking to understand before investing
non-trivial time in reworking my app for continuous deployment. My
objective is to refresh the beanfactory/model (application.cs, a
model-glue parent bean factory) independent of model-glue while live
in production and under load.
I've confirmed to my satisfaction that the following code will update
my application's parent beanfactory in MG 3.1.299:
<cfset
application[this.realName].getInternalBeanFactory().setParent(application.cs)
/>
The remaining question at this point is: Are there any downsides to
getModelGlue().getBean()? It appears to be deprecated in favor of the
beans scope but is it just because it's shorter to write? Technically
the beans scope is two less method calls but are there any other
downsides to using getModelGlue().getBean()?
If not, I believe a Coldspring/Model-Glue application can support true
continuous deployment with two conditions:
1. No cached references to the service layer in persistent scopes
(e.g., don't do <cfset session.obj = application.cs.getBean("MySvc")>)
2. Exclusive use of getModelGlue().getBean(beanname) in Controllers
and NO autowiring of service layer objects
Brian
--
--
Model-Glue Sites:
Home Page: http://www.model-glue.com
Documentation: http://docs.model-glue.com
Bug Tracker: http://bugs.model-glue.com
Blog: http://www.model-glue.com/blog
You received this message because you are subscribed to the Google
Groups "model-glue" group.
To post to this group, send email to [email protected]
To unsubscribe from this group, send email to
[email protected]
For more options, visit this group at
http://groups.google.com/group/model-glue?hl=en
---
You received this message because you are subscribed to the Google
Groups "model-glue" group.
To unsubscribe from this group and stop receiving emails from it, send
an email to [email protected]
<mailto:[email protected]>.
For more options, visit https://groups.google.com/d/optout.
--
--
Model-Glue Sites:
Home Page: http://www.model-glue.com
Documentation: http://docs.model-glue.com
Bug Tracker: http://bugs.model-glue.com
Blog: http://www.model-glue.com/blog
You received this message because you are subscribed to the Google
Groups "model-glue" group.
To post to this group, send email to [email protected]
To unsubscribe from this group, send email to
[email protected]
For more options, visit this group at
http://groups.google.com/group/model-glue?hl=en
---
You received this message because you are subscribed to the Google Groups "model-glue" group.
To unsubscribe from this group and stop receiving emails from it, send an email
to [email protected].
For more options, visit https://groups.google.com/d/optout.
