Need help understanding Terminology, and structure.
9 views
Skip to first unread message
shane
Dec 11, 2009, 3:39:22 AM12/11/09
to ColdSpring-Users
Hopefully I can explain this well enough that everyone isn't left
scratching there head.. I've spent the better part of the last week
baby stepping my way in to a FW/1 - ColdSpring - Reactor application.
For the most part, I understand FW/1, and I've created my Reactor
Mappings, and I'm now beginning to integrade ColdSpring in to the
mix. After reading and (attempting to) follow a number of examples,
I've come to the conclusion that either everyone uses the same words
to describe different things, or I still just don't understand it :)
The thing is, I actually have a working model, that does one simple
thing.. The application sets up ColdSpring, and passes it to FW/1 to
be used as its bean Factory
//Application.cfc
function coldSpringSetup(){
bf = CreateObject('component', '/
coldspring.beans.DefaultXmlBeanFactory').init();
bf.loadBeans(expandPath('coldspring.xml.cfm'));
setBeanFactory(bf);
}
function setupApplication() {
coldSpringSetup();
}
//coldspring.xml.cfm
<beans default-autowire="byName">
<bean id="reactorFactory" class="/reactor.reactorFactory">
<constructor-arg name="configuration">
<ref bean="reactorConfig" />
</constructor-arg>
</bean>
<bean id="reactorConfig" class="/reactor.config.config">
<constructor-arg name="pathToConfigXml">
<value>reactor.xml.cfm</value>
</constructor-arg>
/--Cut out the properties--/
</bean>
<bean id="userGateway" factory-bean="reactorFactory" factory-
method="createGateway">
<constructor-arg name="objectAlias">
<value>User</value>
</constructor-arg>
</bean>
<bean id="userRecord" factory-bean="reactorFactory" factory-
method="createRecord">
<constructor-arg name="objectAlias">
<value>User</value>
</constructor-arg>
</bean>
</beans>
//and a simple call to test.
function setupRequest() {
if( NOT structKeyExists(session,"loggedInUserId")
OR structKeyExists(url,"reload")) {
session.loggedInUserId = 1;
}
var security = getController('user');
doController( security, 'userAuthentication' );
}
//controllers/user.cfc
<cffunction access="public" name="userAuthentication" output="false"
returntype="any">
<cfargument name="rc" type="struct" />
<cfscript>
session.user = variables.fw.getBeanFactory().getBean
('userRecord').load(id=session.loggedInUserId);
</cfscript>
</cffunction>
<cfdump var="#session.user#" expand="no" showudfs="yes"
output="browser" format="html" metainfo="yes">
A simple little app, and believe it or not, it actually dumps the full
userRecord object with all the appropriate reactor generated methods.
So, on to the newbie question(s). In all the how-to's, examples,
quickstart guides, etc.. There is case after case after case of
people creating chains of CFCs, DSN's that inject in to DAO's, that
inject in to Services, that inject in to Factories, that create Domain
objects, etc... and they use terms like "Gateway" and "Service", in
what appear to be completely different context's... and quite frankly,
I'm confused..
Stop me if I'm wrong, because I'm just brain dumping here. But with
Reactor -- I have a "Gateway" and as you can see above, I have created
it as a bean in ColdSpring. This allows me to do some basic functions
like getAll(), getByQuery(), and getByFields()..
I also have a DAO, (which I suppose I could make a bean, but
haven't... is there a need?) and a Record (which I have made a bean,
for testing purposes.) but I also realize that this is probably not
appropriate, and I need a generic Factory that will create and delete
these types of Objects as needed?
I'm banging my head on the door here, because I feel like I'm i just
rolled my pants up and got my feet wet, and.. well.. I just have to be
missing something.. Either that, or EVERY other how-to I've read, has
to custom create models, and services, and gateways.. because they
aren't using an ORM?
Right now, with the above code, I can do:
session.user.setFirst_Name('Shane').save() <-- and the damn thing
updates the database! (easily amused, I know)
So, now that you're bored.. here are my primary questions. In Sean's
FW/1 UserManager examples, he has both controllers, and services that
somewhat mirror each other in that they have setters and getters on
the object, and define the dependancies between departments and
users.. But I don't really need that, do I? Do I need to mimic the
inheritance of my database in services that call the Reactor beans? I
just can't see why that would make sense, but I can't help but think
that I'm simply missing something.
The other thing I can't fully wrap my head around is the whole concept
of "Gateways".. the Reactor Gateways are simply a window in to a
table.. and I can't see why I would need to inject any one of them in
to any other.. The Records, sure.. The user has multiple profiles
that are assigned one of the user types, and has multiple e-mails,
multiple orders, etc.. I think it's safe to assume that I should have
"All" my Reactor gateways created in ColdSpring, just for easy access
to them. But I could really use some better examples on the
appropriate way to move forward from here. I don't like thinking "if
I can make it work without it.. I must not need it".. but maybe it
really is as simple as that? Some examples show a userService that is
injected with any number of related objects. Is that what I should be
shooting for? Creating a userService that is injected with
userRecord, userProfile, userType, userSubType, location,
userProfileEmail, etc, etc.. and then create an actual /services/
user.cfc that handles all these transactions in one full swoop?
I need a nap..
scratching there head.. I've spent the better part of the last week
baby stepping my way in to a FW/1 - ColdSpring - Reactor application.
For the most part, I understand FW/1, and I've created my Reactor
Mappings, and I'm now beginning to integrade ColdSpring in to the
mix. After reading and (attempting to) follow a number of examples,
I've come to the conclusion that either everyone uses the same words
to describe different things, or I still just don't understand it :)
The thing is, I actually have a working model, that does one simple
thing.. The application sets up ColdSpring, and passes it to FW/1 to
be used as its bean Factory
//Application.cfc
function coldSpringSetup(){
bf = CreateObject('component', '/
coldspring.beans.DefaultXmlBeanFactory').init();
bf.loadBeans(expandPath('coldspring.xml.cfm'));
setBeanFactory(bf);
}
function setupApplication() {
coldSpringSetup();
}
//coldspring.xml.cfm
<beans default-autowire="byName">
<bean id="reactorFactory" class="/reactor.reactorFactory">
<constructor-arg name="configuration">
<ref bean="reactorConfig" />
</constructor-arg>
</bean>
<bean id="reactorConfig" class="/reactor.config.config">
<constructor-arg name="pathToConfigXml">
<value>reactor.xml.cfm</value>
</constructor-arg>
/--Cut out the properties--/
</bean>
<bean id="userGateway" factory-bean="reactorFactory" factory-
method="createGateway">
<constructor-arg name="objectAlias">
<value>User</value>
</constructor-arg>
</bean>
<bean id="userRecord" factory-bean="reactorFactory" factory-
method="createRecord">
<constructor-arg name="objectAlias">
<value>User</value>
</constructor-arg>
</bean>
</beans>
//and a simple call to test.
function setupRequest() {
if( NOT structKeyExists(session,"loggedInUserId")
OR structKeyExists(url,"reload")) {
session.loggedInUserId = 1;
}
var security = getController('user');
doController( security, 'userAuthentication' );
}
//controllers/user.cfc
<cffunction access="public" name="userAuthentication" output="false"
returntype="any">
<cfargument name="rc" type="struct" />
<cfscript>
session.user = variables.fw.getBeanFactory().getBean
('userRecord').load(id=session.loggedInUserId);
</cfscript>
</cffunction>
<cfdump var="#session.user#" expand="no" showudfs="yes"
output="browser" format="html" metainfo="yes">
A simple little app, and believe it or not, it actually dumps the full
userRecord object with all the appropriate reactor generated methods.
So, on to the newbie question(s). In all the how-to's, examples,
quickstart guides, etc.. There is case after case after case of
people creating chains of CFCs, DSN's that inject in to DAO's, that
inject in to Services, that inject in to Factories, that create Domain
objects, etc... and they use terms like "Gateway" and "Service", in
what appear to be completely different context's... and quite frankly,
I'm confused..
Stop me if I'm wrong, because I'm just brain dumping here. But with
Reactor -- I have a "Gateway" and as you can see above, I have created
it as a bean in ColdSpring. This allows me to do some basic functions
like getAll(), getByQuery(), and getByFields()..
I also have a DAO, (which I suppose I could make a bean, but
haven't... is there a need?) and a Record (which I have made a bean,
for testing purposes.) but I also realize that this is probably not
appropriate, and I need a generic Factory that will create and delete
these types of Objects as needed?
I'm banging my head on the door here, because I feel like I'm i just
rolled my pants up and got my feet wet, and.. well.. I just have to be
missing something.. Either that, or EVERY other how-to I've read, has
to custom create models, and services, and gateways.. because they
aren't using an ORM?
Right now, with the above code, I can do:
session.user.setFirst_Name('Shane').save() <-- and the damn thing
updates the database! (easily amused, I know)
So, now that you're bored.. here are my primary questions. In Sean's
FW/1 UserManager examples, he has both controllers, and services that
somewhat mirror each other in that they have setters and getters on
the object, and define the dependancies between departments and
users.. But I don't really need that, do I? Do I need to mimic the
inheritance of my database in services that call the Reactor beans? I
just can't see why that would make sense, but I can't help but think
that I'm simply missing something.
The other thing I can't fully wrap my head around is the whole concept
of "Gateways".. the Reactor Gateways are simply a window in to a
table.. and I can't see why I would need to inject any one of them in
to any other.. The Records, sure.. The user has multiple profiles
that are assigned one of the user types, and has multiple e-mails,
multiple orders, etc.. I think it's safe to assume that I should have
"All" my Reactor gateways created in ColdSpring, just for easy access
to them. But I could really use some better examples on the
appropriate way to move forward from here. I don't like thinking "if
I can make it work without it.. I must not need it".. but maybe it
really is as simple as that? Some examples show a userService that is
injected with any number of related objects. Is that what I should be
shooting for? Creating a userService that is injected with
userRecord, userProfile, userType, userSubType, location,
userProfileEmail, etc, etc.. and then create an actual /services/
user.cfc that handles all these transactions in one full swoop?
I need a nap..
Brian Kotek
Dec 11, 2009, 4:25:18 PM12/11/09
to coldspri...@googlegroups.com
On Fri, Dec 11, 2009 at 3:39 AM, shane <spit...@gmail.com> wrote:
So, on to the newbie question(s). In all the how-to's, examples,
quickstart guides, etc.. There is case after case after case of
people creating chains of CFCs, DSN's that inject in to DAO's, that
inject in to Services, that inject in to Factories, that create Domain
objects, etc... and they use terms like "Gateway" and "Service", in
what appear to be completely different context's... and quite frankly,
I'm confused..
Service layer: This is the public interface to the model, and should encapsulate all business logic in the system.
http://martinfowler.com/eaaCatalog/serviceLayer.html
http://www.briankotek.com/blog/index.cfm/2006/9/5/Controller-Layer-vs-Service-Layer
Gateway: This is an interface to an external resource, in this case a database table or set of related tables.
http://martinfowler.com/eaaCatalog/tableDataGateway.html
http://martinfowler.com/eaaCatalog/gateway.html
I also have a DAO, (which I suppose I could make a bean, but
haven't... is there a need?) and a Record (which I have made a bean,
for testing purposes.) but I also realize that this is probably not
appropriate, and I need a generic Factory that will create and delete
these types of Objects as needed?
The DAO should probably be a bean as well. You don't want to manage transient objects like a User through ColdSpring for a number of reasons. http://www.coldspringframework.org/coldspring/examples/quickstart/index.cfm?page=singletons
I'm banging my head on the door here, because I feel like I'm i just
rolled my pants up and got my feet wet, and.. well.. I just have to be
missing something.. Either that, or EVERY other how-to I've read, has
to custom create models, and services, and gateways.. because they
aren't using an ORM?
If you're not using an ORM, then yes, the gateway and the domain objects (like a User) need to be created by the developer.
So, now that you're bored.. here are my primary questions. In Sean's
FW/1 UserManager examples, he has both controllers, and services that
somewhat mirror each other in that they have setters and getters on
the object, and define the dependancies between departments and
users.. But I don't really need that, do I? Do I need to mimic the
inheritance of my database in services that call the Reactor beans? I
just can't see why that would make sense, but I can't help but think
that I'm simply missing something.
Well, I can't tell you whether or not you need it or not, since it depends on what you're doing. I'm not sure what you mean by "mimicking the inheritance of your database in services that call Reactor beans". But if you have a User and related objects, along with it's supporting database tables, then good practice would be to create a UserService to encapsulate that and provide a public interface that the rest of your application can use. The services can also be called remotely via AJAX, AMF, SOAP, etc.
The other thing I can't fully wrap my head around is the whole concept
of "Gateways".. the Reactor Gateways are simply a window in to a
table.. and I can't see why I would need to inject any one of them in
to any other..
Hopefully the links above help clarify the purpose of a gateway. You only would if one gateway needs to do something that involves other tables that are handled by a separate gateway.
Some examples show a userService that is
injected with any number of related objects. Is that what I should be
shooting for? Creating a userService that is injected with
userRecord, userProfile, userType, userSubType, location,
userProfileEmail, etc, etc.. and then create an actual /services/
user.cfc that handles all these transactions in one full swoop?
Well, don't couple different classes together unless there is some reason to do so. But you wouldn't inject a UserRecord, Profile, etc. into the UserService, because the creation of those is handled by Reactor. You'd probably inject a UserGateway, UserDAO, etc. into the UserService, and the service would call the gateway and/or DAO when it needs to get users, save a user, create a user, etc.
Brian
shane
Dec 11, 2009, 11:59:13 PM12/11/09
to ColdSpring-Users
No only did you read it all, you actually took the time to respond to
it too :) thanks Brian..
I don't know why... I'm just having a hard time trying to figure out
exactly what the correct path is to make my application not a
'hack' (at least as far as that is possible). With ReactorFactory,
It creates the DAO, and a few other classes that are used to get/load/
save any record from any table in the database. I guess I'm just
thinking too much about how much of that I can incorporate in to my
application, and how much of it I really should rewrite to just "use"
that factory.
Take for example. under Reactor, there is a /records/userRecord.cfc
which is an empty class that extends the actual userRecord.cfc which
contains all the default functionality to create a user object, modify
the data, save it, etc.. and because of the oneToMany and ManyToOne
relationships I setup in the reactor.xml file, just that object gives
me an interface in to just about every other object that interacts in
some way with a user.
So.. From the way I'm looking at my application, I should probably
create a custom userManager.cfc that also uses a userFactory.cfc to
create multiple instances of the User object (if necessary).. and act
as a gateway for the application controller to access the database.
But, its it proper to actually use the factory to create an instance
of the actual userRecord.cfc that ReactorFactory created for me? I'm
thinking that doing so "couples" my userManager to Reactor.. which
probably isn't proper.. what if I wanted to use Transfer the next time
around? It would probably be better to just create an empty local
user.cfc that extends the reactor user object, no?
I think I'm sort of opening a hole in my dark web.. I just don't know
enough about Reactor, and server memory.. and I'm making a lot of
"assumptions" at this point as to what the best way to go about this
all is.. Right now, I've created userManager, storeManager,
cartManager objects, and those I am setting up in ColdSpring to be
injected with the ReactorFactory bean that is also getting created
there. At this point, those are about the only things that I can think
of that would be completely correct to put in the Application scope...
most everything else is going to be setup per session, or per
request. And that worries me a little.. because I've been watching
the template executions as I'm playing around, and even with some
pretty simple tasks, Reactor is doing an awful lot of work.
Shane
it too :) thanks Brian..
I don't know why... I'm just having a hard time trying to figure out
exactly what the correct path is to make my application not a
'hack' (at least as far as that is possible). With ReactorFactory,
It creates the DAO, and a few other classes that are used to get/load/
save any record from any table in the database. I guess I'm just
thinking too much about how much of that I can incorporate in to my
application, and how much of it I really should rewrite to just "use"
that factory.
Take for example. under Reactor, there is a /records/userRecord.cfc
which is an empty class that extends the actual userRecord.cfc which
contains all the default functionality to create a user object, modify
the data, save it, etc.. and because of the oneToMany and ManyToOne
relationships I setup in the reactor.xml file, just that object gives
me an interface in to just about every other object that interacts in
some way with a user.
So.. From the way I'm looking at my application, I should probably
create a custom userManager.cfc that also uses a userFactory.cfc to
create multiple instances of the User object (if necessary).. and act
as a gateway for the application controller to access the database.
But, its it proper to actually use the factory to create an instance
of the actual userRecord.cfc that ReactorFactory created for me? I'm
thinking that doing so "couples" my userManager to Reactor.. which
probably isn't proper.. what if I wanted to use Transfer the next time
around? It would probably be better to just create an empty local
user.cfc that extends the reactor user object, no?
I think I'm sort of opening a hole in my dark web.. I just don't know
enough about Reactor, and server memory.. and I'm making a lot of
"assumptions" at this point as to what the best way to go about this
all is.. Right now, I've created userManager, storeManager,
cartManager objects, and those I am setting up in ColdSpring to be
injected with the ReactorFactory bean that is also getting created
there. At this point, those are about the only things that I can think
of that would be completely correct to put in the Application scope...
most everything else is going to be setup per session, or per
request. And that worries me a little.. because I've been watching
the template executions as I'm playing around, and even with some
pretty simple tasks, Reactor is doing an awful lot of work.
Shane
Gavin Baumanis
Dec 12, 2009, 5:38:47 AM12/12/09
to coldspri...@googlegroups.com
Hi Shane great questions...
And I was very pleased with Brian's explanation and and links too - thanks...
I do have a question though - "for those in the know".
I understand that the service layer or "Manager" object is the public interface
And that the gateway is where I stick in all the DB "stuff" that the manager calls to do data persistence / retrieval.
But I always though that the DAO and Gateway were interchangeable.
According mr:Google, "definition Data Access Object" returns,
In computer software, a data access object (DAO) is an object that
provides an abstract interface to some type of database or persistence
Which is what "I" call a gateway.
So I am now a little confused, because in your descriptions, Brian - you seem to be saying they are different?
Gavin
--
You received this message because you are subscribed to the Google Groups "ColdSpring-Users" group.
To post to this group, send email to coldspri...@googlegroups.com.
To unsubscribe from this group, send email to coldspring-use...@googlegroups.com.
For more options, visit this group at http://groups.google.com/group/coldspring-users?hl=en.
James Holmes
Dec 12, 2009, 8:00:39 AM12/12/09
to coldspri...@googlegroups.com
Quoth Sean Corfield:
http://corfield.org/blog/index.cfm/do/blog.entry/entry/The_DAO_and_Gateway_separation_in_CFML_is_nonsense
mxAjax / CFAjax docs and other useful articles:
http://www.bifrost.com.au/blog/
2009/12/12 Gavin Baumanis <be...@palcare.com.au>:
http://corfield.org/blog/index.cfm/do/blog.entry/entry/The_DAO_and_Gateway_separation_in_CFML_is_nonsense
mxAjax / CFAjax docs and other useful articles:
http://www.bifrost.com.au/blog/
2009/12/12 Gavin Baumanis <be...@palcare.com.au>:
Brian Kotek
Dec 12, 2009, 12:56:37 PM12/12/09
to coldspri...@googlegroups.com
They are pretty much interchangable, but given all the questions the OP already had, I wasn't going to go down that road. I tend to just have DAOs, and place all my DB-related code in those.
shane
Dec 12, 2009, 1:17:59 PM12/12/09
to ColdSpring-Users
For me, It comes down to understanding concepts, so far.. I find
myself unable to think 'outside the box' and hang up on the singular
representation of a "gateway" rather than the "concept of a
gateway".. When I look in the Reactor generated code, there is a
"tablenameGateway.cfc" created for every table in the database.. I
have a "user" table.. so I see a userGateway, with three functions in
it and find myself stumped thinking that I have to find a way to use
that "userGateway" as the gateway to my user Object.. which obviously
is completely incorrect. the reactor tablenameGateway objects are
nothing more than a query gateway in to the tablename Table, and I
can't think of a valid reason as to why it would make sense to create
everyone of those as beans (unless it is a matter of processing
overhead.. which is what I don't know at this point).. I have the
ReactorFactory as a bean, and I can use coldspring to inject that
reactorFactory in to any other bean object that I create, and then I
should be able to use that reactorFactory in limitless ways inside
those objects.
Someone please correct me if I'm wrong.. but I don't see the point in
creating a bean mapping to the userGateway userProfileGateway
userTypeGateway userSubTypeGateway userProfileLocationGateway (etc,
etc) objects in ColdSpring, and having them all created as
singletons.. (OR) is that actually a smart thing to do? If I simply
create the reactorFactory bean in ColdSpring and have it injected in
to my other beans, how much processing overhead is required to say
<cfset variables.userGateway = getReactorFactory().createGateway
("user") /> in my own services when I want to do a query, rather than
having a single bean created in ColdSpring called "userGateway" that I
can access from anywhere? Or, even one step further.. I see in a lot
of Reactor's own files that it creates these as function specific
objects all over the place! I see in it's own tablenameDao objects,
it makes calls like this <cfset var userGateway = _getReactorFactory
().createGateway("user") /> in every single function.. I'm assuming
that I need to be doing the same thing, or I might have different
functions sharing that same query gateway and stepping on each others
stuff, right? Am I actually on to something here? :) Something that
would at least resemble 'understanding' ? or am I way off track..
On Dec 12, 3:38 am, Gavin Baumanis <b...@palcare.com.au> wrote:
> Hi Shane great questions...
> And I was very pleased with Brian's explanation and and links too - thanks...
>
> I do have a question though - "for those in the know".
> I understand that the service layer or "Manager" object is the public interface
>
> And that the gateway is where I stick in all the DB "stuff" that the manager calls to do data persistence / retrieval.
>
> But I always though that the DAO and Gateway were interchangeable.
> According mr:Google, "definition Data Access Object" returns,
> In computer software, a data access object (DAO) is an object that provides an abstract interface to some type of database or persistence
>
> Which is what "I" call a gateway.
>
> So I am now a little confused, because in your descriptions, Brian - you seem to be saying they are different?
>
> Gavin
>
> On 12/12/2009, at 08:25 , Brian Kotek wrote:
>
>
>
>
>
> > On Fri, Dec 11, 2009 at 3:39 AM, shane <spitt...@gmail.com> wrote:
>
> > So, on to the newbie question(s). In all the how-to's, examples,
> > quickstart guides, etc.. There is case after case after case of
> > people creating chains of CFCs, DSN's that inject in to DAO's, that
> > inject in to Services, that inject in to Factories, that create Domain
> > objects, etc... and they use terms like "Gateway" and "Service", in
> > what appear to be completely different context's... and quite frankly,
> > I'm confused..
>
> > Service layer: This is the public interface to the model, and should encapsulate all business logic in the system.
> >http://martinfowler.com/eaaCatalog/serviceLayer.html
> >http://www.briankotek.com/blog/index.cfm/2006/9/5/Controller-Layer-vs...
myself unable to think 'outside the box' and hang up on the singular
representation of a "gateway" rather than the "concept of a
gateway".. When I look in the Reactor generated code, there is a
"tablenameGateway.cfc" created for every table in the database.. I
have a "user" table.. so I see a userGateway, with three functions in
it and find myself stumped thinking that I have to find a way to use
that "userGateway" as the gateway to my user Object.. which obviously
is completely incorrect. the reactor tablenameGateway objects are
nothing more than a query gateway in to the tablename Table, and I
can't think of a valid reason as to why it would make sense to create
everyone of those as beans (unless it is a matter of processing
overhead.. which is what I don't know at this point).. I have the
ReactorFactory as a bean, and I can use coldspring to inject that
reactorFactory in to any other bean object that I create, and then I
should be able to use that reactorFactory in limitless ways inside
those objects.
Someone please correct me if I'm wrong.. but I don't see the point in
creating a bean mapping to the userGateway userProfileGateway
userTypeGateway userSubTypeGateway userProfileLocationGateway (etc,
etc) objects in ColdSpring, and having them all created as
singletons.. (OR) is that actually a smart thing to do? If I simply
create the reactorFactory bean in ColdSpring and have it injected in
to my other beans, how much processing overhead is required to say
<cfset variables.userGateway = getReactorFactory().createGateway
("user") /> in my own services when I want to do a query, rather than
having a single bean created in ColdSpring called "userGateway" that I
can access from anywhere? Or, even one step further.. I see in a lot
of Reactor's own files that it creates these as function specific
objects all over the place! I see in it's own tablenameDao objects,
it makes calls like this <cfset var userGateway = _getReactorFactory
().createGateway("user") /> in every single function.. I'm assuming
that I need to be doing the same thing, or I might have different
functions sharing that same query gateway and stepping on each others
stuff, right? Am I actually on to something here? :) Something that
would at least resemble 'understanding' ? or am I way off track..
On Dec 12, 3:38 am, Gavin Baumanis <b...@palcare.com.au> wrote:
> Hi Shane great questions...
> And I was very pleased with Brian's explanation and and links too - thanks...
>
> I do have a question though - "for those in the know".
> I understand that the service layer or "Manager" object is the public interface
>
> And that the gateway is where I stick in all the DB "stuff" that the manager calls to do data persistence / retrieval.
>
> But I always though that the DAO and Gateway were interchangeable.
> According mr:Google, "definition Data Access Object" returns,
> In computer software, a data access object (DAO) is an object that provides an abstract interface to some type of database or persistence
>
> Which is what "I" call a gateway.
>
> So I am now a little confused, because in your descriptions, Brian - you seem to be saying they are different?
>
> Gavin
>
> On 12/12/2009, at 08:25 , Brian Kotek wrote:
>
>
>
>
>
> > On Fri, Dec 11, 2009 at 3:39 AM, shane <spitt...@gmail.com> wrote:
>
> > So, on to the newbie question(s). In all the how-to's, examples,
> > quickstart guides, etc.. There is case after case after case of
> > people creating chains of CFCs, DSN's that inject in to DAO's, that
> > inject in to Services, that inject in to Factories, that create Domain
> > objects, etc... and they use terms like "Gateway" and "Service", in
> > what appear to be completely different context's... and quite frankly,
> > I'm confused..
>
> > Service layer: This is the public interface to the model, and should encapsulate all business logic in the system.
> >http://martinfowler.com/eaaCatalog/serviceLayer.html
>
> > Gateway: This is an interface to an external resource, in this case a database table or set of related tables.
> >http://martinfowler.com/eaaCatalog/tableDataGateway.html
> >http://martinfowler.com/eaaCatalog/gateway.html
>
> > I also have a DAO, (which I suppose I could make a bean, but
> > haven't... is there a need?) and a Record (which I have made a bean,
> > for testing purposes.) but I also realize that this is probably not
> > appropriate, and I need a generic Factory that will create and delete
> > these types of Objects as needed?
>
> > The DAO should probably be a bean as well. You don't want to manage transient objects like a User through ColdSpring for a number of reasons.http://www.coldspringframework.org/coldspring/examples/quickstart/ind...
> > Gateway: This is an interface to an external resource, in this case a database table or set of related tables.
> >http://martinfowler.com/eaaCatalog/tableDataGateway.html
> >http://martinfowler.com/eaaCatalog/gateway.html
>
> > I also have a DAO, (which I suppose I could make a bean, but
> > haven't... is there a need?) and a Record (which I have made a bean,
> > for testing purposes.) but I also realize that this is probably not
> > appropriate, and I need a generic Factory that will create and delete
> > these types of Objects as needed?
>
Brian Kotek
Dec 12, 2009, 1:28:29 PM12/12/09
to coldspri...@googlegroups.com
Again, it depends, there is no rulebook for this. I don't use Reactor and haven't for a long time, so your questions may be better answered on the Reactor list. I don't know how much overhead there is in calling createGateway() all over your code, but personally, yes I would create singleton beans for each gateway and inject them into other beans. My goal being, I want to decouple my application from the fact that I am using Reactor as much as I can. Let fewer dependencies my actual code has on with ORM implementation I am using, the better.
Brian Kotek
Dec 12, 2009, 1:29:21 PM12/12/09
to coldspri...@googlegroups.com
That should say "The fewer dependencies my actual code has on with ORM implementation I am using, the better."
Brian Kotek
Dec 12, 2009, 1:31:00 PM12/12/09
to coldspri...@googlegroups.com
Ugh! ACTUALLY it should say "THE fewer dependencies my actual code has on WHICH ORM implementation I am using, the better."
shane
Dec 12, 2009, 3:00:43 PM12/12/09
to ColdSpring-Users
I agree with the overall concept, I just am not sure that it is
possible in a practical sense, unless I'm also going to create
function mapping classes between the service and the ORM too.. From
what I understand, in order to successfully inject the reactorfactory
in to my userManager, I have to either have getReactorFactory and
setReactorFactory functions in my manager, or I have to accept them in
the init() function. So, right there, I've 'coupled' my manager to
the ORM. I supposed I could have getGenericORMFactory and
setGenericORMFactory functions instead, so my model didn't care what
ORM factory was coming in.. but then I would have the problem of non-
standard function names between typical ORM's.. and I couldn't assume
anywhere in my manager that the ORM methods I'm calling would exist
when I just changed the ORM in the ColdSpring file.. I can't see a
cost effective solution to that... at least not in the scope of the
applications that I'm writing :)
Shane
On Dec 12, 11:31 am, Brian Kotek <brian...@gmail.com> wrote:
> Ugh! ACTUALLY it should say "THE fewer dependencies my actual code has on
> WHICH ORM implementation I am using, the better."
>
>
>
> On Sat, Dec 12, 2009 at 1:29 PM, Brian Kotek <brian...@gmail.com> wrote:
> > That should say "The fewer dependencies my actual code has on with ORM
> > implementation I am using, the better."
>
possible in a practical sense, unless I'm also going to create
function mapping classes between the service and the ORM too.. From
what I understand, in order to successfully inject the reactorfactory
in to my userManager, I have to either have getReactorFactory and
setReactorFactory functions in my manager, or I have to accept them in
the init() function. So, right there, I've 'coupled' my manager to
the ORM. I supposed I could have getGenericORMFactory and
setGenericORMFactory functions instead, so my model didn't care what
ORM factory was coming in.. but then I would have the problem of non-
standard function names between typical ORM's.. and I couldn't assume
anywhere in my manager that the ORM methods I'm calling would exist
when I just changed the ORM in the ColdSpring file.. I can't see a
cost effective solution to that... at least not in the scope of the
applications that I'm writing :)
Shane
On Dec 12, 11:31 am, Brian Kotek <brian...@gmail.com> wrote:
> Ugh! ACTUALLY it should say "THE fewer dependencies my actual code has on
> WHICH ORM implementation I am using, the better."
>
>
>
> On Sat, Dec 12, 2009 at 1:29 PM, Brian Kotek <brian...@gmail.com> wrote:
> > That should say "The fewer dependencies my actual code has on with ORM
> > implementation I am using, the better."
>
Kevan Stannard
Dec 12, 2009, 3:14:17 PM12/12/09
to coldspri...@googlegroups.com
Shane, take a look at this post to see how you can avoid coupling of the Reactor Factory directly to your UserManager.
Brian Kotek
Dec 12, 2009, 3:23:51 PM12/12/09
to coldspri...@googlegroups.com
There are several patterns that deal with the issue of handling different families of objects with different APIs, including Adapter and Facade. If you switched ORMs, nothing should know outside of the Gateway/DAO layer.
Brian Kotek
Dec 12, 2009, 3:37:33 PM12/12/09
to coldspri...@googlegroups.com
So very quickly, something along this line:
http://yuml.me/29818264
Again, note that you don't have to take this approach until you actually need to switch ORMs. The point is, if ORM-specific logic is encapsulated within the data access layer, you are free to make this change later without affecting anything else in the application.
http://yuml.me/29818264
Again, note that you don't have to take this approach until you actually need to switch ORMs. The point is, if ORM-specific logic is encapsulated within the data access layer, you are free to make this change later without affecting anything else in the application.
Reply all
Reply to author
Forward
0 new messages