Entity beans. How low can ya go?

[Brian H.]

Hey folks.

Trying to leverage OO for the first time in a “real” application, and
I’m running into architectural challenges at every turn. I would
really appreciate some feedback from those who have actually developed
some CF OO apps.

My app is pretty straight forward. Projects, Staff, Tasks. Each are
first-class citizens, have their own service objects, factories, DAOs,
etc. My plan (which may or may not be sound) is to have Project beans
consist of one or more staff beans (assigned staff), and one or more
task beans (tasks for the proj). Task beans consist of one or more
Staff beans (staff assigned to this task). Staff beans consist of one
or more task beans (task to which they are assigned).


Question 1: How deep do entity beans go? When I envision a fully
hydrated Project bean, I imagine it containing an array of fully
hydrated Task beans. But, a fully hydrated Task bean contains an array
of Staff beans (all assigned staff to that task). Then those Staff
beans, once hydrated, should consist of an array of other task beans,
etc, ad nauseum.

This is obviously not going to work. Not only would my ProjectDAO
produce mammoth project beans (each consisting of just about my entire
database), but it would produce cyclical dependencies. This leads to
question 2 bellow.


Question 2. Do you use “composition” to express “association”
relationships between entity beans? The problem from question 1 is
that I am using composition (creating a new bean) in place of
association (grabbing a link to an existing bean). That is, in my
ProjectDAO, when I am instantiating a project bean, and I go to grab a
bunch of Staff beans to load them into an array inside the project
bean, I am creating those staff beans from scratch (eg, composition)
and not simply pulling a reference to them (which is more like
association). I see association all the time with wiring up my service
singleton objects using coldspring, but I’ve never seen an example of
association using entity beans.


Question 3: Do your DAOs depend on your service layer? Right now,
when my app needs a Project bean, it calls getProject() on my service
layer, which calls read() on my ProjectDAO. The thing is, my
ProjectDAO needs to grab Task beans, so in coldspring, I pass a
reference to my TaskService into my ProjectDAO, so it can call the
TaskService.getTask() method. This seems a bit weird, and anti-
hierarchical.


Bonus Question: Does anyone ever pass a Boolean flag to their DAO
called “shallow”, which causes the DAO to return a partially hydrated
bean, say, a Project bean without any composed Staff or Task beans?

I greatly appreciate feedback here as I am simply spinning my wheels

-Brian

[Mark Mandel]

Brian,

Some thoughts -

On Thu, Sep 3, 2009 at 6:33 AM, Brian H. <bhe...@gmail.com> wrote:

Hey folks.

Trying to leverage OO for the first time in a “real” application, and
I’m running into architectural challenges at every turn. I would
really appreciate some feedback from those who have actually developed
some CF OO apps.

My app is pretty straight forward.  Projects, Staff, Tasks. Each are
first-class citizens, have their own service objects, factories, DAOs,
etc.  

You may want to read up what got coined the '5-1 syndrome'.  You really don't want a Service/factory/dao/gateway for each bean (that's even greater than 5-1). Really think about having you Service layer grouped per functionality group.

Sean Corfield wrote a really good article on this in a FAQU article a while back... and I've totally forgotten which issue it was.

Really think about your Service layer being the public facing API to the rest of your application.
 

My plan (which may or may not be sound) is to have Project beans
consist of one or more staff beans (assigned staff), and one or more
task beans (tasks for the proj).  Task beans consist of one or more
Staff beans (staff assigned  to this task). Staff beans consist of one
or more task beans (task to which they are assigned).


Question 1: How deep do entity beans go?  When I envision a fully
hydrated Project bean, I imagine it containing an array of fully
hydrated Task beans. But, a fully hydrated Task bean contains an array
of Staff beans (all assigned staff to that task). Then those Staff
beans, once hydrated, should consist of an array of other task beans,
etc, ad nauseum.

This is where the platform you are working on can change the way you approach this greatly.

In an ideal world, where performance was no concern, you would do exactly as you described and life would be hunky-dory, as you could traverse relationships ad nauseum, and that would make life super happy.

But obviously performance is a concern, and memory, therefore doing this means you have work around these limitations.

1) This is where an ORM would lazy load.  I.e. you would get a Project bean, and Tasks would only be loaded when requested.  This ensures the performance hit you get for doing the work you are doing is directly relative to what you are asking for.

That being said, even using lazy loading can have its drawbacks.  Say a project has 1000 Tasks. Even if this is lazy loaded, this could still be a performance concern, as 1000 objects loaded at once could end up being slow.

2) Use a query. Maybe your project bean simply returns a list of its tasks as a query. It's not as OO nice as an array of Beans, but it gets the job done, and performance isn't as much a concern.  In your Task Bean, you can set it up to know about the project (manytoone), but you don't then need to worrk about huge collections of objects.

 

This is obviously not going to work. Not only would my ProjectDAO
produce mammoth project beans (each consisting of just about my entire
database), but it would produce cyclical dependencies. This leads to
question 2 bellow.


Question 2.  Do you use “composition” to express “association”
relationships between entity beans? The problem from question 1 is
that I am using composition (creating a new bean) in place of
association (grabbing a link to an existing bean). That is, in my
ProjectDAO, when I am instantiating a project bean, and I go to grab a
bunch of Staff beans to load them into an array inside the project
bean, I am creating those staff beans from scratch (eg, composition)
and not simply pulling a reference to them (which is more like
association). I see association all the time with wiring up my service
singleton objects using coldspring, but I’ve never seen an example of
association using entity beans.

Not sure what you are driving at here.  Are you asking if your Staff beans should be pulling from some kinda of cache?

Question 3: Do your DAOs depend on your service layer?  Right now,
when my app needs a Project bean, it calls getProject() on my service
layer, which calls read() on my ProjectDAO. The thing is, my
ProjectDAO needs to grab Task beans, so in coldspring, I pass a
reference to my TaskService into my ProjectDAO, so it can call the
TaskService.getTask() method.  This seems a bit weird, and anti-
hierarchical.

This is where having a single DAO/Service for each bean gets you into a bit of trouble.

But I see no issue with a DAO needing an external Service.  If that is the dependency as your application needs it, then so be it.
 

Bonus Question: Does anyone ever pass a Boolean flag to their DAO
called “shallow”, which causes the DAO to return a partially hydrated
bean, say, a Project bean without any composed Staff or Task beans?

Given that building lazy loading into your own Objects is a real pain... I can't see any problems with this approach at all.

But as said before as well, you could just return queries for those 'list'' items, and that would help a lot.

Hope that helps!

Mark

--
E: mark....@gmail.com
T: http://www.twitter.com/neurotic
W: www.compoundtheory.com

[Guilherme Pinto]

I'm no design expert, but sounds like your relationships should be
kept in the database and not as nested properties in your beans.

In your project bean your getStaff method would fetch the data from
the database using the project OID as the lookup key.

Same idea for the other beans.

Hope that helps.

Guilherme

Sent from my iPhone

[Brian H.]

Hey guys.

Sorry for the long reply. I've thought about everything that was
mentioned here but just didn't articulate a response.

I had an moment of clarity today, and I think that lazy loading is the
way to go. I was really wanting to keep my beans "pure" and not
contain any references to my DAOs, but I think the tiny bit of logic
required to pull "child" objects into the bean when required (lazy
load) is insignificant next to the advantages of doing so.

As for arrays of beans, and I agree that the solution should match the
situation. If you are writing a performance sensitive app under heavy
load, then I might avoid arrays of beans unless they would be very
small arrays. For many other sites, I think that it is justifiable,
especially with the performance gains in CF9 with respect to object
instantiation (See here for a great writeup:
http://jamiekrug.com/blog/index.cfm/2009/7/21/cfc-creation-time-in-coldfusion-8-9-open-bluedragon-11-and-railo-31
)

Thanks for the responses guys.

-Brian

On Sep 2, 5:10 pm, Guilherme Pinto <gpi...@fotogram.com> wrote:
> I'm no design expert, but sounds like your relationships should be  
> kept in the database and not as nested properties in your beans.
>
> In your project bean your getStaff method would fetch the data from  
> the database using the project OID as the lookup key.
>
> Same idea for the other beans.
>
> Hope that helps.
>
> Guilherme
>
> Sent from my iPhone
>