fat bean vs fat service?

[Henry]

I wonder what's prefered... should the bean methods work with
properties of a bean, or should the service methods do everything to a
bean, by calling all the getters and setters?

What do you use?

[Alan Livie]

Fat beans - thin(ish) services.

Alan
________________________________________
From: cfc...@googlegroups.com [cfc...@googlegroups.com] On Behalf Of Henry [henry...@gmail.com]
Sent: 28 August 2008 04:01
To: CFCDev
Subject: [CFCDEV] fat bean vs fat service?

[Brian Kotek]

In an ideal application nothing would ever call a getter or setter. Unfortunately, in reality this is pretty much impossible; data has to get into an object somehow, and it has to be displayed somehow.

In good OO design, objects TELL other objects what to do, they don't ASK other objects for their internal data. This is the basis of the design principle "Tell, don't ask".

[Adam Haskell]

I really don't care for the word beans. They just smack of bad OO to me, same with transfer objects. Throw beans away, focus on domains and what they should DO. Sure maybe it's symantics but I think beans have this context about them of just being glorified structures. If you find yourself writing more .getXXX or .setXXX then anything else then something is either modeled poorly or you are trying to shoe horn something into an OO design that simply does not fit. Is this a bad thing? I suppose it depends on what type of app you are writing. In general Services should just know how to co-ordinate different parts of the model Asking the model to do the necessary tasks to accomplish larger tasks. Sometimes that might result in data passing in or coming out but generally the service should focus on behavior of individual domain objects.


Adam

On Mon, Sep 1, 2008 at 4:44 AM, Alan Livie <ALi...@efinancialcareers.com> wrote:

[Henry]

'Bean' was introduced to me when I was learning Model-Glue.

While I did bindly use bean as instructed by MG and other tuturials on
MG, I found that:

1.) Some thinks bean is nothing more than using CFC as a struct to
hold fields of forms.
2.) Some thinks bean is nothing more than representating a table in
SQL (data-centeric extreme)
3.) Some thinks bean is an object that handles everything internally
and (talks to database)
4.) Some thinks bean is an object that handles everything othan than
talking to database (with external XXXDao.cfc)

I have used a code generator to generate all the getters and setters.
With code folding support by CFEclipse, I don't mind them too much.
Using MG together with ColdSpring, it seems the prefered way is to
code most logics in the Service layer because they will be kept alive
throughout the lifetime of the application through use of Singleton.
However, doesn't that lean towards... procedural programming?

I like the idea of having a "fat bean", and with that I can rely much
less on getters and setters. However, as the object grow larger with
number of methods, wouldn't initializing the object be too expensive
on CF8?

What's your take on fat/lean bean?


Thanks,
Henry Ho

On Sep 2, 12:13 pm, "Adam Haskell" <a.hask...@gmail.com> wrote:
> I really don't care for the word beans. They just smack of bad OO to me,
> same with transfer objects. Throw beans away, focus on domains and what they
> should DO. Sure maybe it's symantics but I think beans have this context
> about them of just being glorified structures. If you find yourself writing
> more .getXXX or .setXXX then anything else then something is either modeled
> poorly or you are trying to shoe horn something into an OO design that
> simply does not fit. Is this a bad thing? I suppose it depends on what type
> of app you are writing. In general Services should just know how to
> co-ordinate different parts of the model Asking the model to do the
> necessary tasks to accomplish larger tasks. Sometimes that might result in
> data passing in or coming out but generally the service should focus on
> behavior of individual domain objects.
>
> Adam
>
> On Mon, Sep 1, 2008 at 4:44 AM, Alan Livie <ALi...@efinancialcareers.com>wrote:
>
>
>
>
>
> > Fat beans - thin(ish) services.
>
> > Alan
> > ________________________________________
> > From: cfc...@googlegroups.com [cfc...@googlegroups.com] On Behalf Of Henry

> > [henryho...@gmail.com]

> > Sent: 28 August 2008 04:01
> > To: CFCDev
> > Subject: [CFCDEV] fat bean vs fat service?
>
> > I wonder what's prefered... should the bean methods work with
> > properties of a bean, or should the service methods do everything to a
> > bean, by calling all the getters and setters?
>

> > What do you use?- Hide quoted text -
>
> - Show quoted text -

[Eric Knipp]

Henry I think you have done a good job summarizing the tradeoffs with the bean approach.  The Active Record pattern which you describe in #3 is the "ideal" in terms of OO behavior, but can be hard to use because of performance considerations - this is what frequently drives migration to some combination of #2/#4.  ColdFusion has the added problem of object instantiation performance penalties beyond what you would expect from many other languages - there's another discussion on this topic raging right now as the IBO anti-pattern is discussed.

I don't think there is a perfect solution.  You will probably be forced to compromise some aspect of object-orientedness to get better performance characteristics from your application.

--
Eric Knipp
Advanced Certified ColdFusion MX Developer
http://erichk.instantspot.com/blog/

[Peter Bell]

@Eric,

There isn't anything more ideal about 3 over 4. I happen to like to have an object.save() method that calls the DAO to persist the object, but it's no more or less OO than having an ObjectService.save(Object) method call. Check out Martin Fowlers classic entry on the anaemic domain model, He suggests that persistence strategies are orthogonal to whether the domain model is anaemic. I'd agree.

1 and 2 are sometimes done but are not OO. 3 and 4 are both quite valid approaches.

Also, I don't think an IBO is an anti-pattern. That would suggest it is a common approach that should be avoided as it is a bad design. It may be a kludge, and it may be CF specific, but I'd argue it is a pattern - not an anti pattern.

Best Wishes,

Peter

[Dutch]

While preparing the #variables.nextHoliday# dinner, a child asked her
mother, "Why do you cut off both ends of ham before you cook it?" The
mother responded with, "This is how my mother did it. I don't know
why, you should ask her?" When the child asked her grandmother, she
got the same response as before. She proceeded to ask her great-
grandmother who responded with, "I cut off both ends of the ham
because I didn't have a pan big enough."

As programmers, we often make decisions and writing code based on the
way we learn how other people did something, but not understanding
why.

When it comes to programming, we always like to ask the quetion
"What's the best way to do X?" Everyone has opinions are are willing
to share them. Knowledge sharing is a beautiful thing. When it comes
to best practices, the real answer is that it depends on the context
for which you're crafting a solution.

-Dutch Rapley

[Adam Haskell]

I have to say I agree with Peter's sentiment mostly here. I've considered putting together a top anti-patterns presentation specific to ColdFusion and I say I've never had IBO on that list. That being said DAO has crossed my mind as an anti-pattern. Not so much b/c it itself is a bad design pattern in ColdFusion but the consideration of using it or something else is an anti-pattern. That decision just really should not be a debate, choose one and move on, oh or generate it with one of the umpteenmillion tools. If you are spending time figuring this out your application model is already too data centric, stop using CFCs immediately and just use structures (ok ok don't do that but hopefully you get my point).


Adam Haskell

[Peter Bell]

And interestingly while I was presenting to the NY CFUG the other night and trying to justify to OO n00bs why to bother with DAO's at all (as opposed to just throwing the SQL into the service classes) it finally dawned on me that the main reason is unit testing. Sure it is nice to have the separation of business logic vs sql concerns and theoretically you could swap out DAOs using an abstract factory for different dbms's but that is more useful for frameworks than for most of our day to day apps. The killer benefit of abstracting SQL into a DAO is that you can mock it out for your unit testing,

Best Wishes,

Peter

[Henry]

Hi Peter, I had an idea yesterday during yesterday's Online CF Meetup
with Mark Mandal. When he mentioned slightly about be careful with
<onetomany> because of the large amount of objects that Transfer needs
CF to create (when w/o lazy loading). Then in my mind <blink>IBO!!!</
blink>. What do you think, Peter?


Henry

[Jared Rypka-Hauer]

Hey Henry...

I tend to lean more toward the "fat bean, thin service, thin
controller".

I also pass BOs into the views as the API to the data they contain.

I concede that this is far easier when you're dealing with an ORM
framework like Transfer or Reactor. Building your own complex (read:
adequate for use in an application) is not trivial and without a
framework you end up generating or rolling your own for each project.

I'll grant you that sometimes Reactor and Transfer get in the way, but
the regularity with which this happens and the amount of trouble it
causes is minimal.

I don't think having your bean talk to the DB has to mean Active
Record, either... but it can, and it's neither here nor there.
ActiveRecord is a viable approach to solve a problem and the reasons
people hate it are largely philosophical in that they have everything
to do with theory and nothing to do with the reality of the fact that
it just works, and it can be done well. It can also be done poorly,
but what can't?

I think having your beans be smart enough to deal with things like
login/logout state or persisting their own data, be given access to
the service layer, and encapsulate the real weight of the codebase in
question is a good way to actually model the real-world behavior of
the items they represent. I like to use the example of a conference
attendee, who has to register himself, pick up his attendee kit, show
his badge to the security service and ask the hotel desk service for
his room number (at least once). In most ColdFusion applications, the
services would do all that work, bouncing the user around from desk to
desk giving no real help. In the theoretical approach I prefer, the
user himself decides if he knows enough to answer the question or if
he needs to talk to a service to find out the data.

I think almost everyone is right in practice, to one degree or
another, but not everyone is calling things by the right names... OO
is something specific, and passing transfer objects (aka "beans" most
of the time) around between monolithic services isn't it. Having
robust, well-modeled beans that encapsulate behavior based on their
real-world counterparts is really what OO is all about. My problem is
wiht people who build big, procedural code libraries and then call
themselves OO developers. It ain't so. ;)

I agree with Brian here but want to add DRY to the mix... these two
principles will actually, very organically, tell you where to put the
functionality it your application. The idea is that you have one place
in your application that does Activity X (DRY), and if you have an n-
tier application and you step thru (in your head or on paper... UML
activity diagrams FTW!) how the tiers will interact, there's more than
likely a limited set of options as to where the functionality goes, at
least based on TDA. They can be very helpful little slogans.

Tell, Don't Ask
http://www.pragmaticprogrammer.com/articles/tell-dont-ask

Don't Repeat Yourself (aka DRY)
http://en.wikipedia.org/wiki/Don't_repeat_yourself

And with that, I'm off to encapsulate all this into a blog post. :)
This sort of thing is where 99% of my blog posts come from, so I'm
glad I'm involved in lists again! :D

Laterz,
J