TQL as gateways?

[Luis Majano]

This is a design and architecture question.

As I have been creating more of my service layer for a specific
section and combining it with TQL, the code starts to look very
similar to gateway code for the queries. Now, should these methods
be extracted from the service layer and to a gateway layer even though
its TQL??

Example:

Service Layer: user service
method: getUsersByName()
- TQL setup
- TQL Execution

Should it be moved to something like:
Service Layer: user service
Gateway : user gateway (Injected with TransferFactory)
method: getUsersByName()
- Call Gateway with parameters
- Return query

So there you go? what do you think? Opinions? Suggestions? Comments?

[John Allen]

I like the second approach.
I think of service layers as a "road-map" for a particular aspect for a request.
Kinda like a "super controller" that orchestrates the other CFC's that interact with db, send emails, and check things.

OT: Mr. Manajo coldBox ROCKS

[Mark Mandel]

Luis,

Yep, I would do it that way -

So:

Service -> Gateway -> Transfer -> TQL

This means that if you ever need to switch out the TQL for plain ol'
SQL, the rest of your application never needs to care.

Mark

--
E: mark....@gmail.com
W: www.compoundtheory.com

[Luis Majano]

Ok dokey!! 10-4

Seemed the most flexible way. Coding changed.

However, for crud operations, they remained on the service layer, just
calling Transfer.
Is this also the case?

LUis

On Apr 19, 3:59 pm, "Mark Mandel" <mark.man...@gmail.com> wrote:
> Luis,
>
> Yep, I would do it that way -
>
> So:
>
> Service -> Gateway -> Transfer -> TQL
>
> This means that if you ever need to switch out the TQL for plain ol'
> SQL, the rest of your application never needs to care.
>
> Mark
>

> On 4/20/07, Luis Majano <lmaj...@gmail.com> wrote:
>
>
>
>
>
> > This is a design and architecture question.
>
> > As I have been creating more of my service layer for a specific
> > section and combining it with TQL, the code starts to look very
> > similar to gateway code for the queries. Now, should these methods
> > be extracted from the service layer and to a gateway layer even though
> > its TQL??
>
> > Example:
>
> > Service Layer: user service
> > method: getUsersByName()
> > - TQL setup
> > - TQL Execution
>
> > Should it be moved to something like:
> > Service Layer: user service
> > Gateway : user gateway (Injected with TransferFactory)
> > method: getUsersByName()
> > - Call Gateway with parameters
> > - Return query
>
> > So there you go? what do you think? Opinions? Suggestions? Comments?
>
> --

> E: mark.man...@gmail.com
> W:www.compoundtheory.com

[Mark Mandel]

Personally,

I actually abstract it out to -

Service -> DAO -> Transfer -> CRUD

I personally like a high level of abstraction.

Mark

[John Allen]

Heck yea, our good buddy Transfer is like all the other cfc's doing things.
Mr. Transfer so good at it to.

On 4/19/07, Luis Majano < lma...@gmail.com> wrote:

[John Allen]

I like Marks idea!
Going to redo something right now.
danks

[John Allen]

Ohhhhhh,
That way the ORM isnt peppered in your service layer!
Good idea.
(but you know how crazy i am bout your transfer, i LIKE having it peppered in my service layers.)

[Jaime Metcher]

Boy, my coding style is more perverted than I thought (which is saying a lot):

To deal with multiple instances or get an instance:
Controller -> Class Singleton -> Transfer or SQL

To do instance things where the instance needs to worry about larger issues:
Controller -> Instance -> Class Singleton -> Transfer or SQL

To do instance things that only concern the instance:
Controller -> Instance -> Transfer

But only occasionally, when doing more far reaching things:
Controller -> Service -> Class Singletons -> etc.

But I'm the kind of guy who is always going into a shop, asking for something that seems reasonable to me, and getting blank stares.  The words are in English, but it seems the thought processes are something foreign.

Jaime Metcher

[Peter Bell]

I kind of see class singleton and service solving the same class of problems (new(), getbyPropertyValue(), getByFIlter(), deleteByFilter(), deletebyPropertyValue(), etc.) with the business object (instance) handling (via a composed DAO) save and of course all of its getter and setter and validation logic.

Do you find any benefits in distinguishing service method from class singleton? Would love to see example of the kind of methods names that’d go into each . . .

Side comment - I would consider seriously wrapping transfer within a single DAO that can be composed into both your class singleton and instance. In that way if you ever wanted to switch out the persistence mechanism, you’d only have to change your DAO (did Mark just say that a couple of emails back? Been skimming too fast today :-<).

Best Wishes,
Peter

[John Allen]

I like ColdSpring (or Lightwire) to handle my singleton issues explicitly in the XML.
Makes the concept of "service" layers, IMHO, super easy to deal with and maintain, cause you just write a little story about what your data is supposed to do, then all the worker guys (emailer, db stuff [ORM], notification ect) to there thing totally independently, and my boy ColdSpring deals with all that other stuff (thank goodness for frameworks).
I could be totally wak bout thinking this way!?! Hope not.

[Jaime Metcher]

I'd put all the methods you mention in a class object, as well as class-level validation (like uniqueness constraints) and also anything else that's of interest regarding the class as a whole.

Just as interesting is what I *don't* put into a class object.  I have a set of rules for class objects - this looks picky, but for me it flows naturally from the concept.  I'll use class User with a related singleton UserClass as an example
1. All instances of User must be created by UserClass
2. All instances of User must have a reference to UserClass and vice versa
3. UserClass must not directly instantiate any instances that are not of class User (it could call another class object to instantiate objects of other classes)

i.e. CreateObject is quarantined to within class objects to guarantee you don't get "naked" classless instances.  This is just plumbing that's handled automatically in other languages.  It gives me class methods and class variables.

So this looks like service/gateway functionality, but if I was writing a service that had to deal with a variety of classes, it would be using a variety of class objects to do that. Benefits?  High coherency.  A class object should be highly coherent, a service should be as coherent as it needs to be.

I should add that I'm not recommending this - I have it on good authority that the fact that it makes sense to me doesn't mean it will make sense for anyone else.  Newbs - listen to someone else!

I know what you mean about putting a DAO layer in front of Transfer, and in theory I like it.  But when I think about, we're talking about three interfaces:
1) my DAO layer's interface
2) Transfer's interface
3) the interface of ORM xyz, which maybe will replace transfer
So what this means is getting 2) and maybe later 3) to conform to 1).  To make this easy, why not say 1) is the same as 2), given that 2) is a nice interface already?  Then I only have to make 3) conform to 2), and that might not even happen.  In which case, why bother with 1) at all?  Which means that today, I can just deal with one interface, not two or three.  YAGNI.  Not being flippant here, I just find it hard to see the benefit.

Jaime

[Peter Bell]

Hi Jamie,

Great comments. The difference between our approaches is that I currently make my service methods object specific, so they are in effect your class singletons. I let LightWire do my instance creation, but I do inject references of the service method (your singleton class) and the DAO into my instances, and I guess I don’t have the equivalent of your service classes at the moment – probably because I don’t have much orchestration across objects that requires business rules, so typically my controllers will handle cross object issues and that has been fine so far as there really hasn’t been any business logic involved yet that I might want to abstract into the model. That is one design decision I’m not at all sure about though as I have a feeling it is a function of the simplicity of the apps I’m currently generating.

Could you share some general ideas of the kind of cross object things that your service classes handle?

Fascinating discussion!

Best Wishes,
Peter

[Jaime Metcher]

On 4/20/07, Peter Bell <pb...@systemsforge.com> wrote:

Hi Jamie,

Great comments. The difference between our approaches is that I currently make my service methods object specific, so they are in effect your class singletons.

Yep.

I let LightWire do my instance creation, but I do inject references of the service method (your singleton class) and the DAO into my instances, and I guess I don't have the equivalent of your service classes at the moment –

Neither do I, really!  I can see where I'd use them to implement a facade for e.g. Flex, but right now, not really.
 

probably because I don't have much orchestration across objects that requires business rules, so typically my controllers will handle cross object issues and that has been fine so far as there really hasn't been any business logic involved yet that I might want to abstract into the model.

Me too.
 

That is one design decision I'm not at all sure about though as I have a feeling it is a function of the simplicity of the apps I'm currently generating.

Yeah, I wonder too.  I wonder also if this is to do with the smart service/dumb object idea - may if your business objects are smarter the service layer is less useful?  Dunno.  It's a very fuzzy distinction anyway.
 

Could you share some general ideas of the kind of cross object things that your service classes handle?

I'm slowly moving a large procedural system to OO, one bite at a time, starting with the model and any new controllers.  No existing tests! Nerve-wracking stuff!  As mentioned, I haven't got as far as a service layer yet, so I'm not speaking from experience, but as I move further up the food chain I can see there will be cross object interactions that are more general than a single controller.  Reporting, data archiving etc. come to mind, although these might be just facades on a set of stored procedures.  Also there's a big ball of mud or two that I might just end up wrapping.  I know that's a facade, but that kind of matches how I think about services.

Jaime Metcher

[Peter Bell]

Fascinating stuff. Best of luck and please keep us posted as your thinking evolves!

Best Wishes,
Peter

On 4/20/07 1:44 AM, "Jaime Metcher" <jmet...@gmail.com> wrote:

On 4/20/07, Peter Bell <pb...@systemsforge.com> wrote:

Hi Jamie,

Great comments. The difference between our approaches is that I currently make my service methods object specific, so they are in effect your class singletons.

Yep.

I let LightWire do my instance creation, but I do inject references of the service method (your singleton class) and the DAO into my instances, and I guess I don't have the equivalent of your service classes at the moment ˆ

[John Allen]

Id be excited to hear how this works out for ya too.
ja

On 4/20/07, Peter Bell <system...@gmail.com > wrote:

[Luis Majano]

Great comments guys.

I have also a similar setup to what Peter has. I also think that the
service layer can be a bit more flexible to class singletons in the
fact that I can create some service layers that can encompass several
composite classes. This way I do not go in the way of modeling, for
example every single class, but implement a facade according to
behavior. This in turns, simplifies my objects, relations and
interfaces. My service layer in itself is unique per class or class
compositions (via behavior or relations) and interfacing to my DAO and
Gateway layers.

Gateways with Transfer encapsulated seems great. I have all my queries
in one location, search, and also because I can mix in some plain OLD
stored procedure calls or other complex queries into the mix.

As for DAO, abstracting it even more, is tempting, but I am finding
that is adding another level of abstraction that might not be
necessary, unless you are thinking that you will swap out your
persistence mechanism. And with the fact the I will be replacing the
two lines of code needed to call a CRUD operation via Transfer. I
guess I am in a dilemma of best practices of architectural design with
ease of use and practicality (with minor design issues). I guess I
don't have a clear path in this area yet.

Luis

On Apr 20, 9:31 am, "John Allen" <johnfal...@gmail.com> wrote:
> Id be excited to hear how this works out for ya too.
> ja
>

> On 4/20/07, Peter Bell <systemsfo...@gmail.com> wrote:
>
>
>
> > Fascinating stuff. Best of luck and please keep us posted as your
> > thinking evolves!
>
> > Best Wishes,
> > Peter
>

> > On 4/20/07 1:44 AM, "Jaime Metcher" <jmetc...@gmail.com> wrote: