Passing the datasource variable
10 views
Skip to first unread message
sli...@gmail.com
Mar 5, 2008, 9:31:18 AM3/5/08
to Mach-II for ColdFusion
Hi guys,
I am currently working on my model, and I am wondering about the best
way to get my datasource variable into my gateways and DAOs. I have a
dsnRead and a dsnWrite datasource property both set in my config file.
I am then calling that property in my listener and passing it through
to my service, and then through to my gateway/dao.
The reason I am doing it this way is so that I can keep my model
separate from controller. Is there a better way of doing this, maybe
eliminating the constant passing of the datasource, and still keep my
model and controllers separate? For instance, I don't want to directly
invoke mach-ii's 'getProperty() function in my gateway or dao.
I am currently working on my model, and I am wondering about the best
way to get my datasource variable into my gateways and DAOs. I have a
dsnRead and a dsnWrite datasource property both set in my config file.
I am then calling that property in my listener and passing it through
to my service, and then through to my gateway/dao.
The reason I am doing it this way is so that I can keep my model
separate from controller. Is there a better way of doing this, maybe
eliminating the constant passing of the datasource, and still keep my
model and controllers separate? For instance, I don't want to directly
invoke mach-ii's 'getProperty() function in my gateway or dao.
Peter Bell
Mar 5, 2008, 9:59:16 AM3/5/08
to mach-ii-for...@googlegroups.com
Do you need more than one DSN within a given application for a given
DAO/Gateway? If not, you might want to set the properties using ColdSpring -
either within the XML config file, or write a script to generate an XML
object based on your config file and to pass that into ColdSpring on load.
DAO/Gateway? If not, you might want to set the properties using ColdSpring -
either within the XML config file, or write a script to generate an XML
object based on your config file and to pass that into ColdSpring on load.
Best Wishes,
Peter
Matt Woodward
Mar 5, 2008, 10:07:48 AM3/5/08
to mach-ii-for...@googlegroups.com
Sounds like you're going about it right. You actually can't call
getProperty() in your service, gateway, or DAO, so calling it in your
listener and then passing it in is the way to go. Or, you can use
ColdSpring and set properties in your non-Mach-II objects that way.
getProperty() in your service, gateway, or DAO, so calling it in your
listener and then passing it in is the way to go. Or, you can use
ColdSpring and set properties in your non-Mach-II objects that way.
Bear in mind this is a one-time thing as well--iow you should be
instantiating your service in your listener when it first gets
created, and in turn your dao and gateway get instantiated in your
service, but only once. Let me know if that doesn't make sense.
--
Matt Woodward
mpwoo...@gmail.com
http://www.mattwoodward.com
sli...@gmail.com
Mar 5, 2008, 10:11:52 AM3/5/08
to Mach-II for ColdFusion
Well, I would love to try and delve into coldspring, but It took quite
some convincing to get the team to seriously look at mach-ii and to
make the move from procedural to OO programming. (well, at least i've
convinced my supervisor and system adminsitrator) Its going to really
be a stretch for our whole shop to move from procedural to OO here, so
at the moment coldspring is out of the question as trying to add even
more complexity will probably fry the whole thing.
And to answer your question about multiple DSNs, yes. We have a server
dedicated for writing, and one dedicated for reading thus two
datasources in the coldfusion server admin. Has to do with optimizing
the servers and access speeds into the database and all that stuff. Im
no system admin so I can't explain it all.
On Mar 5, 8:59 am, Peter Bell <systemsfo...@gmail.com> wrote:
> Do you need more than one DSN within a given application for a given
> DAO/Gateway? If not, you might want to set the properties using ColdSpring -
> either within the XML config file, or write a script to generate an XML
> object based on your config file and to pass that into ColdSpring on load.
>
> Best Wishes,
> Peter
>
some convincing to get the team to seriously look at mach-ii and to
make the move from procedural to OO programming. (well, at least i've
convinced my supervisor and system adminsitrator) Its going to really
be a stretch for our whole shop to move from procedural to OO here, so
at the moment coldspring is out of the question as trying to add even
more complexity will probably fry the whole thing.
And to answer your question about multiple DSNs, yes. We have a server
dedicated for writing, and one dedicated for reading thus two
datasources in the coldfusion server admin. Has to do with optimizing
the servers and access speeds into the database and all that stuff. Im
no system admin so I can't explain it all.
On Mar 5, 8:59 am, Peter Bell <systemsfo...@gmail.com> wrote:
> Do you need more than one DSN within a given application for a given
> DAO/Gateway? If not, you might want to set the properties using ColdSpring -
> either within the XML config file, or write a script to generate an XML
> object based on your config file and to pass that into ColdSpring on load.
>
> Best Wishes,
> Peter
>
sli...@gmail.com
Mar 5, 2008, 10:14:07 AM3/5/08
to Mach-II for ColdFusion
Oh, okay Matt. You answered my question. Seems the only way to do what
I am asking is to utilize coldspring which is out of the question for
the time being. Thanks much guys.
On Mar 5, 9:07 am, "Matt Woodward" <mpwoodw...@gmail.com> wrote:
> Sounds like you're going about it right. You actually can't call
> getProperty() in your service, gateway, or DAO, so calling it in your
> listener and then passing it in is the way to go. Or, you can use
> ColdSpring and set properties in your non-Mach-II objects that way.
>
> Bear in mind this is a one-time thing as well--iow you should be
> instantiating your service in your listener when it first gets
> created, and in turn your dao and gateway get instantiated in your
> service, but only once. Let me know if that doesn't make sense.
>
> On Wed, Mar 5, 2008 at 9:31 AM, bpick...@forumcomm.com
I am asking is to utilize coldspring which is out of the question for
the time being. Thanks much guys.
On Mar 5, 9:07 am, "Matt Woodward" <mpwoodw...@gmail.com> wrote:
> Sounds like you're going about it right. You actually can't call
> getProperty() in your service, gateway, or DAO, so calling it in your
> listener and then passing it in is the way to go. Or, you can use
> ColdSpring and set properties in your non-Mach-II objects that way.
>
> Bear in mind this is a one-time thing as well--iow you should be
> instantiating your service in your listener when it first gets
> created, and in turn your dao and gateway get instantiated in your
> service, but only once. Let me know if that doesn't make sense.
>
>
> <slim...@gmail.com> wrote:
>
> > Hi guys,
> > I am currently working on my model, and I am wondering about the best
> > way to get my datasource variable into my gateways and DAOs. I have a
> > dsnRead and a dsnWrite datasource property both set in my config file.
> > I am then calling that property in my listener and passing it through
> > to my service, and then through to my gateway/dao.
>
> > The reason I am doing it this way is so that I can keep my model
> > separate from controller. Is there a better way of doing this, maybe
> > eliminating the constant passing of the datasource, and still keep my
> > model and controllers separate? For instance, I don't want to directly
> > invoke mach-ii's 'getProperty() function in my gateway or dao.
>
> --
> Matt Woodward
> mpwoodw...@gmail.comhttp://www.mattwoodward.com> <slim...@gmail.com> wrote:
>
> > Hi guys,
> > I am currently working on my model, and I am wondering about the best
> > way to get my datasource variable into my gateways and DAOs. I have a
> > dsnRead and a dsnWrite datasource property both set in my config file.
> > I am then calling that property in my listener and passing it through
> > to my service, and then through to my gateway/dao.
>
> > The reason I am doing it this way is so that I can keep my model
> > separate from controller. Is there a better way of doing this, maybe
> > eliminating the constant passing of the datasource, and still keep my
> > model and controllers separate? For instance, I don't want to directly
> > invoke mach-ii's 'getProperty() function in my gateway or dao.
>
> --
> Matt Woodward
Dan Wilson
Mar 5, 2008, 10:32:59 AM3/5/08
to mach-ii-for...@googlegroups.com
bpickens,
I can feel your pain. There is definitely a process risk in changing too much at once. We all know developers feel uncomfortable changing and I am sure you have enough to combat with moving everyone to MachII.
There are serious benefits in using MachII with ColdSpring. I don't think I would build an application with MachII that DIDN'T use ColdSpring. Try to keep your objects nice and tidy so you can migrate that way when the environment lends itself to such things.
About your two datasource issue, I've worked on systems like that. The reasoning is because the replication between databases has a certain amount of overhead. Having one database read only helps speed up the access on the machine. Pushing all the writes through another database gives the system time to push those changes over a clear channel. One database is constantly notifying the other database of the change in state.
If both databases constantly changed and had to notify each other of changes, then it becomes a little messy to handle conflict resolution. i.e. if the same record was changed at the same time. Also, having this master-slave situation helps in testing and debugging the database cluster. It is a fine architectural setup.
As a developer, it comes to how you handle this. If you were not using ColdSpring, then you could simply pass 2 arguments into each DAO. One for reads and one for writes. You would, of course, need to think carefully about where to store these DSNs, as you wouldn't want hardcoded DSNs every single place you create your DAOs. It just gets unmanageable.
If you were using ColdSpring, then you could define these DSNs once in the ColdSpring.xml file. Then, pass a reference to each DAO on creation. This would help keep the hardcoded DSN references in one single place. Sort of like a config file for your cfcs.
Hope this helps.
DW--
"Come to the edge, he said. They said: We are afraid. Come to the edge, he said. They came. He pushed them and they flew."
Guillaume Apollinaire quotes
I can feel your pain. There is definitely a process risk in changing too much at once. We all know developers feel uncomfortable changing and I am sure you have enough to combat with moving everyone to MachII.
There are serious benefits in using MachII with ColdSpring. I don't think I would build an application with MachII that DIDN'T use ColdSpring. Try to keep your objects nice and tidy so you can migrate that way when the environment lends itself to such things.
About your two datasource issue, I've worked on systems like that. The reasoning is because the replication between databases has a certain amount of overhead. Having one database read only helps speed up the access on the machine. Pushing all the writes through another database gives the system time to push those changes over a clear channel. One database is constantly notifying the other database of the change in state.
If both databases constantly changed and had to notify each other of changes, then it becomes a little messy to handle conflict resolution. i.e. if the same record was changed at the same time. Also, having this master-slave situation helps in testing and debugging the database cluster. It is a fine architectural setup.
As a developer, it comes to how you handle this. If you were not using ColdSpring, then you could simply pass 2 arguments into each DAO. One for reads and one for writes. You would, of course, need to think carefully about where to store these DSNs, as you wouldn't want hardcoded DSNs every single place you create your DAOs. It just gets unmanageable.
If you were using ColdSpring, then you could define these DSNs once in the ColdSpring.xml file. Then, pass a reference to each DAO on creation. This would help keep the hardcoded DSN references in one single place. Sort of like a config file for your cfcs.
Hope this helps.
DW
"Come to the edge, he said. They said: We are afraid. Come to the edge, he said. They came. He pushed them and they flew."
Guillaume Apollinaire quotes
Peter Bell
Mar 5, 2008, 11:15:43 AM3/5/08
to mach-ii-for...@googlegroups.com
While it is in general not a good design approach, I might consider just putting the two DSNs in application scope, have all of your DAOs and Gateways extend a BaseDAO and BaseGateway and put two lines in the init() method of each:
variables.ReadDSN = application.ReadDSN;
variables.WriteDSN = application.WriteDSN;
Then when you do move to ColdSpring (it’ll happen eventually!), you could replace those two lines with two setter injections in the base classes and you’d be done in ten minutes as all of the references within the beans would be to the DSNs in the variables scope. Also, you may find a BaseDAO and BaseGateway to be useful as I often find I can abstract out a bunch of SQL from the individual classes, replacing them with parameterized base class calls.
Anyone got thoughts on this? I don’t do it, but it doesn’t seem an unreasonable trade off to me even though in the general case referencing the application scope within your beans is a pretty bad idea. Of course, if you were planning to try to re-use your beans across projects this would start to become a bad idea very quickly indeed.
Best Wishes,
Peter
variables.ReadDSN = application.ReadDSN;
variables.WriteDSN = application.WriteDSN;
Then when you do move to ColdSpring (it’ll happen eventually!), you could replace those two lines with two setter injections in the base classes and you’d be done in ten minutes as all of the references within the beans would be to the DSNs in the variables scope. Also, you may find a BaseDAO and BaseGateway to be useful as I often find I can abstract out a bunch of SQL from the individual classes, replacing them with parameterized base class calls.
Anyone got thoughts on this? I don’t do it, but it doesn’t seem an unreasonable trade off to me even though in the general case referencing the application scope within your beans is a pretty bad idea. Of course, if you were planning to try to re-use your beans across projects this would start to become a bad idea very quickly indeed.
Best Wishes,
Peter
sli...@gmail.com
Mar 5, 2008, 11:33:30 AM3/5/08
to Mach-II for ColdFusion
Yeah, our model is going to essentially service multiple newspaper
websites. I'm not sure if that is the same thing as re-using them
across projects...
On Mar 5, 10:15 am, Peter Bell <systemsfo...@gmail.com> wrote:
> While it is in general not a good design approach, I might consider just
> putting the two DSNs in application scope, have all of your DAOs and
> Gateways extend a BaseDAO and BaseGateway and put two lines in the init()
> method of each:
>
> variables.ReadDSN = application.ReadDSN;
> variables.WriteDSN = application.WriteDSN;
>
> Then when you do move to ColdSpring (it¹ll happen eventually!), you could
> replace those two lines with two setter injections in the base classes and
> you¹d be done in ten minutes as all of the references within the beans would
> be to the DSNs in the variables scope. Also, you may find a BaseDAO and
> BaseGateway to be useful as I often find I can abstract out a bunch of SQL
> from the individual classes, replacing them with parameterized base class
> calls.
>
> Anyone got thoughts on this? I don¹t do it, but it doesn¹t seem an
> unreasonable trade off to me even though in the general case referencing the
> application scope within your beans is a pretty bad idea. Of course, if you
> were planning to try to re-use your beans across projects this would start
> to become a bad idea very quickly indeed.
>
> Best Wishes,
> Peter
>
> > On Wed, Mar 5, 2008 at 10:11 AM, bpick...@forumcomm.com <slim...@gmail.com>
websites. I'm not sure if that is the same thing as re-using them
across projects...
On Mar 5, 10:15 am, Peter Bell <systemsfo...@gmail.com> wrote:
> While it is in general not a good design approach, I might consider just
> putting the two DSNs in application scope, have all of your DAOs and
> Gateways extend a BaseDAO and BaseGateway and put two lines in the init()
> method of each:
>
> variables.ReadDSN = application.ReadDSN;
> variables.WriteDSN = application.WriteDSN;
>
> Then when you do move to ColdSpring (it¹ll happen eventually!), you could
> replace those two lines with two setter injections in the base classes and
> you¹d be done in ten minutes as all of the references within the beans would
> be to the DSNs in the variables scope. Also, you may find a BaseDAO and
> BaseGateway to be useful as I often find I can abstract out a bunch of SQL
> from the individual classes, replacing them with parameterized base class
> calls.
>
> Anyone got thoughts on this? I don¹t do it, but it doesn¹t seem an
> unreasonable trade off to me even though in the general case referencing the
> application scope within your beans is a pretty bad idea. Of course, if you
> were planning to try to re-use your beans across projects this would start
> to become a bad idea very quickly indeed.
>
> Best Wishes,
> Peter
>
Matt Woodward
Mar 5, 2008, 11:34:44 AM3/5/08
to mach-ii-for...@googlegroups.com
I go back and forth on this sort of thing pretty frequently. To me
while this isn't ideal, it's not the worst thing in the world to do.
If you wanted to get really crazy with it you could write a facade so
you aren't referencing application. directly, but honestly this is all
CF code so unless something totally bizarre happens in the future,
you'll always have access to the application scope.
while this isn't ideal, it's not the worst thing in the world to do.
If you wanted to get really crazy with it you could write a facade so
you aren't referencing application. directly, but honestly this is all
CF code so unless something totally bizarre happens in the future,
you'll always have access to the application scope.
Just curious why moving these objects across projects would be so
bad--as long as you're consistent it should just work, you'd just have
to remember to have the dsns in your application scope.
All this being said I don't do this myself, and I'd strongly, strongly
suggest getting on ColdSpring as soon as possible, but in the interim
this doesn't seem like such a horrendously bad approach to me.
--
Adrian J. Moreno
Mar 5, 2008, 11:39:27 AM3/5/08
to mach-ii-for...@googlegroups.com
We use at least six (6) different data sources throughout our
applications. We store a struct in the session scope (soon moving to the
application scope) that contains keys for each DSN.
applications. We store a struct in the session scope (soon moving to the
application scope) that contains keys for each DSN.
When we create an object, we inject that variable via init():
<cffunction name="init">
<cfargument name="DSN" type="struct" required="true" />
<cfset variables.DSN = arguments.DSN />
<cfreturn this />
</cffunction>
<cfset myCFC = createObject("component", "path.to.MyCFC").init( DSN =
application.DSN ) />
Then we can call whichever DSN we need inside the CFC:
<cffunction name="getSomeData" returntype="query">
<cfset var foo = "" />
<cfquery name="foo" datasource="#variables.DSN.dsn_a#">
...
</cfquery>
<cfreturn foo />
</cffunction>
This has worked extremely well for us. When we started our site redesign
project, we were in the same boat re ColdSpring. We had a hard enough
time getting OOP concepts accepted by parts of the team that had never
programmed like that before, plus CS hadn't released version 1.0 yet.
I will recommend that if you're not going to use ColdSpring, look into
Object Factories. You'll get the benefits of CS without learning a new
framework.
I couldn't really begin to describe why we have so many data sources,
but it's been interesting, let me tell you. :)
-- Adrian
sli...@gmail.com
Mar 5, 2008, 11:46:29 AM3/5/08
to Mach-II for ColdFusion
... Man, you have no idea. We actually have between 40 and 50
datasources currently. Were just starting to make the switch to the
read/write datasources and eliminating others. (due to spagettii code,
this is a massive undertaking...)
On Mar 5, 10:39 am, "Adrian J. Moreno" <amor...@iKnowKungFoo.com>
wrote:
> >> On Wed, Mar 5, 2008 at 10:11 AM, bpick...@forumcomm.com <slim...@gmail.com>
datasources currently. Were just starting to make the switch to the
read/write datasources and eliminating others. (due to spagettii code,
this is a massive undertaking...)
On Mar 5, 10:39 am, "Adrian J. Moreno" <amor...@iKnowKungFoo.com>
wrote:
Peter Bell
Mar 5, 2008, 11:54:02 AM3/5/08
to mach-ii-for...@googlegroups.com
Sounds like we're about on the same page.
Reason this gets harder for object reuse is that it's a slippery slope. Just
wait until you have 60 projects with beans from each relying on a different
subset of 200 application variables - it becomes a real pain to handle the
"which properties are required by which bean in which application" stuff.
The reason (for me) to avoid application scope is that you're creating
undocumented dependencies within the bean and the more of those you have,
the more likely you are to run into issues when re-using the beans.
That said, in this case, it's what I'd do if I wasn't using ColdSpring or
something similar.
Best Wishes,
Peter
Reply all
Reply to author
Forward
0 new messages