"I explained that it was good practice to separate out the plublic API
from
the gateway and gave the example of changing database providers. "

Not sure that's a great argument - changing DB's is very rare in
projects.

Question:  Does your app consist of just database calls, or is there
ever any "business logic" type stuff going on too?

IMHO, a greater reason to isolate queries to their own "gateway layer"
is that queries tend to be large, ugly things that makes business
logic header to read.  IE, if your service layer consists of both
business logic and queries, it's harder to see the business logic.

Having only methods in the gateway that return queries (instead of
structs) also encourages code re-use, ie, method "a" might want the
data as a query for easy display, method "b" might want the data as
struct because it's gotta add form data to is to work out how/what to
save or what's changed.

The duplication isn't too hard to deal with either. Write your wrapper
cfFunction in the service layer, copy/paste it to the gateway layer
and replace the contents with a cfquery tag.  Probably adds a minute
or two per method.


dave





On Jan 4, 11:46 am, Gavin Baumanis <beauecli...@gmail.com> wrote:
> Hi Everyone,
>
> I was recently chatting at work about how we might go about architecting a
> new application.
> I suggested that we have;
> Objects,
> Service Managers
> and Gateways.
>
> Whereby the ServiceManager is the public API for the gateway.
>
> Then I got asked , "Why?"
>
> I explained that it was good practice to separate out the plublic API from
> the gateway and gave the example of changing database providers.
> Eg. Swapping from MS-SQL server to PostGreSQL.
>
> With my architecture proposal, you only need to change the gateway (perhaps
> some minor tweaks to the ServiceManager CFCs.
>
> So far so goo... Until I got asked "Why" again.
> "You still need to change the code somewhere for the new database flavour.
> What is the ServiceManager  doing for us, it seems like a redundant
> duplication of code?"
>
> Subsequently, I have been thinking about it more - and can't come up with a
> good reason.
>
> I could be doing it completely wrong...
> But for the most part, my Service layer becomes a duplicate of the Gateway.
> * Ensure we have the required arguments for the gateway,
> * Call the gateway functions, using the supplied arguments
> * Return exactly the gateway's return value(s) to the consumer.
>
> 99.9% of the time the arguments are exactly the same,
> The data / structure (whatever) that is returned from the gateway, is
> returned unaltered to the consumer, too.
> For the very small number of times that I might do some data transformation
> (in the ServiceManager) before it is returned... well I could simply create
> "THAT" method in my gateway and have;
> * Call the this.GETTER method
> * Transform the data as required
> * Return the transformed data
>
> So am I missing something? Or have I just talked myself out of the
> requirement for (perhaps, excluding web-services) of ever needing to have a
> separate service layer to a Gateway CFC?
>
> Gavin.

-- 
You received this message because you are subscribed to the Google Groups 
"cfaussie" group.
To post to this group, send email to cfaussie@googlegroups.com.
To unsubscribe from this group, send email to 
cfaussie+unsubscr...@googlegroups.com.
For more options, visit this group at 
http://groups.google.com/group/cfaussie?hl=en.

Reply via email to