Handling Reporting as objects / Services etc.

[James Buckingham]

Hi group,

We're just in the final stages of building our latest application and we're now being asked to create a backend reporting tools to help staff with the results that'll come through.

From an OO / behaviour point of view I'm in a bit of a dilemma on how to approach this one. On one side I've got all these objects & services like....

StudentService ( Student Object )
FinanceService ( Finance Object )
InstalmentService ( Payment Instalment options )
etc.

.... nicely separated out.

Now I've got a requirement to build a reporting tool for things like "Get All the Students and all the instalment plans they've chosen".

Part of me wants to keep these Services away from this and have all my DAO querying etc. managed with something like a specific reporting services. The other part of me thinks that the ownership for these objects should really belong to the services still and instead I should create a Facade to call in what's needed

When it comes to methods like though getAllStudentInstalments() there is that obvious dilemma of who owns this and the DAOs

Any ideas / feedback is appreciated :-)

James

[John Whish]

When it comes to reports, I usually find that straight SQL is the
best. So I'd create a report service (and DAO/gateway if you wish) and
put it in there.

> --
> You received this message because you are subscribed to the Google Groups
> "Object-Oriented Programming in ColdFusion" group.
> To view this discussion on the web visit
> https://groups.google.com/d/msg/coldfusionoo/-/MmdxZE9Z7BoJ.
> To post to this group, send email to coldfu...@googlegroups.com.
> To unsubscribe from this group, send email to
> coldfusionoo...@googlegroups.com.
> For more options, visit this group at
> http://groups.google.com/group/coldfusionoo?hl=en.
>

[Peter Oliver-Krueger]

Just had a similar discussion with one of my developers.  Only the CUD operations in CRUD are specific to one table at a time, so it's so much easier to create a DAO around those and identify who owns or has permissions.  It's that darn R(ead) operation that blows the best laid plans to hell, especially when the client decides that they want a whole series of joins for doing comparisons and evaluations.  Just looking at it abstractly, my vote is with John.  Go ahead and create a report service with Read SQL that cross-cuts the different tables, and focus on isolating only the Create, Update, Delete operations to an "owning" object.  That way only one object can ever modify records, but any other object can join to the existing data.  Don't know if that helps.  --Pete

[James Buckingham]

Great thanks a lot for your time guys.

That puts my mind at rest a bit.... Report Service it is then :-)

Cheers,
James

[Sean Corfield]

On Tue, Jun 21, 2011 at 7:57 AM, James Buckingham <clar...@gmail.com> wrote:
> From an OO / behaviour point of view I'm in a bit of a dilemma on how to
> approach this one. On one side I've got all these objects & services
> like....

Ugh! NOT EVERYTHING IS AN OBJECT!

Sorry for shouting. CFML is not Java.

Java forces EVERYTHING to be an object. That is a dumb idea. Java is a
BAD language. There are much better languages on the JVM.

It is just FINE for things to be procedural when it makes sense.
--
Sean A Corfield -- (904) 302-SEAN
An Architect's View -- http://corfield.org/
World Singles, LLC. -- http://worldsingles.com/
Railo Technologies, Inc. -- http://www.getrailo.com/

"Perfection is the enemy of the good."
-- Gustave Flaubert, French realist novelist (1821-1880)

[Jatin Nanda]

Never thought I would say this but "that depends" (sorry Sean)

I have found that quite often clients do not actually know the type of reports they require. They have a rough idea and most likely, based on initial feedback, they will request different ones.

It also depends on how the data is being delivered to the client. Is it in the forms of Excel reports, csvs or actual visualisation. Check out http://www.highcharts.com/

So assuming you client/stake holder is anything like some of my former clients I would suggest get down and dirty with your SQL as its own service - as John said above.

in some cases it will not be worth converting the rows into objects and in other cases it may be the better option.

Apologies for the vagueness :o)

--
You received this message because you are subscribed to the Google Groups "Object-Oriented Programming in ColdFusion" group.

[James Buckingham]

Thanks Sean ( I think! )

Is this not the "Object-Orientated Programming in ColdFusion" group?

I'm really asking how people approach this problem in an OO style ... language aside ( not that I mention anything about Java ).

And with respect I've spent 6+ mths trying to get our team out the habit of writing procedural "spaghetti" code and teach them how to make nice reusable, if you want to call it OO-style, approaches to solving problems.

Telling them that now we're 90% through this to go back to procedural coding, because Sean C. says all this stuff is now dumb, just isn't going to happen.

Thanks again,
James

[James Buckingham]

.... and moving along!

Thanks Jatin.

Yeah I don't think I'll be producing hundreds of objects for the reports. I think it's going to be down to a service(s) depending on how things pan out, calling in the SQL, slapping that maybe in an Iterator and then giving that back to the Controller / Views for display.

Simples :-)

Cheers,
James

[Charlie Griefer]

2 things... inline.

On Thu, Jun 23, 2011 at 1:23 AM, James Buckingham <clar...@gmail.com> wrote:
> And with respect I've spent 6+ mths trying to get our team out the habit of
> writing procedural "spaghetti" code and teach them how to make nice
> reusable, if you want to call it OO-style, approaches to solving problems.

procedural != "spaghetti" code. There can be good, reusable
procedural code just like there can be bad OO spaghetti code.

> Telling them that now we're 90% through this to go back to procedural
> coding, because Sean C. says all this stuff is now dumb, just isn't going to
> happen.

"NOT EVERYTHING IS AN OBJECT" != "all this stuff is dumb"

You're kind of twisting words, when you've already pretty much agreed
to doing exactly what Sean (and everybody before him) is saying...
putting a bunch of SQL queries in a Reporting Service cfc, which isn't
particularly OO. That doesn't make it "bad". You've still got a well
architected application with a clear separation of concerns. It
doesn't automatically mean that the rest of your OO code will turn
into procedural spaghetti, nor does it mean that the rest of the OO
architected code in your app is dumb.

You say you're asking how people approach this problem in an OO
style... and the answer that you've gotten (which again, you seem to
have agreed with), is that they don't. Sean's answer was more or less
the same, except, y'know, with shouting :D

Just sayin'... keep things in perspective :)

--
Charlie Griefer
http://charlie.griefer.com/

I have failed as much as I have succeeded. But I love my life. I love
my wife. And I wish you my kind of success.

[Jose Alfonso]

Thank you Sean! (and you showed some passion there ;-) )

[Sean Corfield]

On Thu, Jun 23, 2011 at 1:23 AM, James Buckingham <clar...@gmail.com> wrote:
> Is this not the "Object-Orientated Programming in ColdFusion" group?

Yes, and me telling you reporting SQL doesn't belong in objects is a
reasonable answer.

> I'm really asking how people approach this problem in an OO style ...
> language aside ( not that I mention anything about Java ).

And I'm saying don't try to shoehorn this sort of stuff into OO.

The whole point of OO is modeling "state + behavior" together. If you
have a pure "service", it's not OO by definition so don't fool
yourself. This is at the root of most of the problems CFers get into
with OO: they try to make _everything_ into an object (and it's partly
Java's fault which requires everything live in a class).

> And with respect I've spent 6+ mths trying to get our team out the habit of
> writing procedural "spaghetti" code and teach them how to make nice
> reusable, if you want to call it OO-style, approaches to solving problems.

And with respect I've been doing OO for 19 years and some of that
experience is when OO is not the right solution :)

I'll say it as plainly as I can:

- OO is not equivalent to well structured maintainable code.
- Procedural is not equivalent to poorly structured unmaintainable spaghetti.

Use OO where it makes sense but don't use it where it doesn't make sense.

[Jatin Nanda]

I miss my Haskell and pascal (delphi as well) days

:o)

--

[James Buckingham]

@Charlie - Thanks for the input :-)

"procedural != "spaghetti" code.  There can be good, reusable procedural code just like there can be bad OO spaghetti code."

Agreed but there is procedural scripts for doing specific tasks ( and I guess in this case a few reports could be classed as that ) and there is writing enterprise applications with it. We've about 10yrs worth of Procedural applications here. Do they work and meet the business requirements? Yeap. Do other staff hear the screams down the corridor coming from our Developers who are trying to support / maintain this "string ball"? Absolutely! 

The tales of old when it comes to "ColdFusion" ring right from that bell.

"You say you're asking how people approach this problem in an OO style... and the answer that you've gotten (which again, you seem to have agreed with), is that they don't.  Sean's answer was more or less the same, except, y'know, with shouting :D"

Yeap I think its a sound approach. Service gives me the SQL and I'm happy to carry on my way with that. I think anything else is probably going to hinder me.

@Sean - Thanks for not shouting this time and giving me some valued input, lol.

If you were to mention the words procedural to any of our team then I'll be seeing cfquerys and business logic slapped at the top of every CFM page before I knew it. That's the immediate image I get if someone suggests the "p" word :-). Maybe the term has thinned out a bit over the years but here it's still a reality that we have to work with that approach.

At the same time I'm by no means looking to slap the phrase "object" on everything I can find. Producing some fantastically encapsulated reporting tool that suits all our needs is just not going to happen IMO.

The approach of encapsulating the SQL and feeding off that in a "service" seems like a good compromise though.

In conclusion - really my main reason for asking was to get an understand of how other Developers have dealt with these requirements themselves and how, since I want to learn more OO techniques, what I should be aware of. 19yrs experience or 1yr we're all trying to share and learn from each other ;-)

Thanks again everyone, appreciate your time.

James

[Larry C. Lyons]

Given your comments you may find this preso useful:
Refactoring a Legacy Application to an MVC Framework - Ezra Parker
http://cfmumbojumbo.com/cf/index.cfm/cfconferences/cfobjective-2011/refactoring-a-legacy-application-to-an-mvc-framework-ezra-parker/

regards,
larry

> --
> You received this message because you are subscribed to the Google Groups
> "Object-Oriented Programming in ColdFusion" group.

> To view this discussion on the web visit

> https://groups.google.com/d/msg/coldfusionoo/-/L-QYqZa87bIJ.

> To post to this group, send email to coldfu...@googlegroups.com.
> To unsubscribe from this group, send email to
> coldfusionoo...@googlegroups.com.
> For more options, visit this group at
> http://groups.google.com/group/coldfusionoo?hl=en.
>

--
Larry C. Lyons
web: http://www.lyonsmorris.com/lyons
LinkedIn: http://www.linkedin.com/in/larryclyons

"I do not feel obliged to believe that the same God who has endowed us
with sense, reason, and intellect has intended us to forgo their use."
Galileo

[James Buckingham]

I will :-).

Thanks Larry

[Larry C. Lyons]

I go through that particular hell every day.

On Thu, Jun 23, 2011 at 2:53 PM, James Buckingham <clar...@gmail.com> wrote:
> I will :-).
> Thanks Larry

>
> --
> You received this message because you are subscribed to the Google Groups
> "Object-Oriented Programming in ColdFusion" group.
> To view this discussion on the web visit

> https://groups.google.com/d/msg/coldfusionoo/-/vifjbW87BesJ.

[Sean Corfield]

On Thu, Jun 23, 2011 at 11:48 AM, James Buckingham <clar...@gmail.com> wrote:
> If you were to mention the words procedural to any of our team then I'll be
> seeing cfquerys and business logic slapped at the top of every CFM page
> before I knew it. That's the immediate image I get if someone suggests the
> "p" word :-). Maybe the term has thinned out a bit over the years but here
> it's still a reality that we have to work with that approach.

Procedural simply means a set of steps. Perhaps saying structured
programming would conjure up the right mental model instead? :)

In the CFML world, we have a bit of a history of using the wrong
terminology - or at least creating new meanings for terminology that
has well-defined meaning in other communities... Just something we
need to be diligent about.

Reporting is, pretty much by definition, large slabs of (procedural)
code based around often complex SQL queries. You don't gain much from
putting this code in a CFC as methods, except perhaps from an
organizational point of view (perhaps some private helper methods).
There's minimal benefit in creating an instance of such CFCs since
there's no state and (probably) no configuration. The overhead of
creating an instance of such CFCs is minimal and you're not likely to
be creating such instances often enough for it to matter (once per
user request, most likely).

In other words, exercise caution when using CFCs for reporting
services so that your developers don't try to treat them like objects
- perhaps always use them via cfinvoke and a component path name so
you guarantee getting a new instance and folks don't try to keep
instances around. You might even consider using custom tags instead,
to emphasize the distinct nature of these beasts (seriously - you need
a strong way to flag these are not "objects" in any traditional
sense).

I think the reason we lean toward CFCs as our unit of organization is
because of our Java influence. Before Java, structured code
organization was possible (and, in fact, widespread) using a variety
of means, including directory or module structuring - and no one was
under any misconception that these blocks of code were somehow
"entities" in the application model.

In some ways, Java has clouded our thinking around structured programming...

Hope that clarifies why I'm pushing back on this issue so strongly?

[Jatin Nanda]

Sean's explanation is much clearer than mine. :o)

Thanks @Sean - you've cleared up my muddied mind again

--

You received this message because you are subscribed to the Google Groups "Object-Oriented Programming in ColdFusion" group.