event-bean calling a ColdSpring bean rather than a CFC

[Matthew]

Hi all

I'm playing around with event-bean. I have everything working when a
use event-bean to populate my bean however I'm now writing the validate
() method on my bean which needs to call the Service/Dao/Gateway to
check some of my bean data against the DB. The problem is that because
the event-bean type="" attribute can only be pointed directly at the
CFC then it isn't instantiated by ColdSpring so none of the
dependencies (e.g. Service) are initialised. Does anyone have a
solution for this? I've had a dig in M2 and can see that it calls the
init() method on the bean so do I need to have all my dependency stuff
hard coded in here and therefore can't use ColdSpring?

Cheers
Matthew

[Peter J. Farrell]

Well, you shouldn't be using ColdSpring to instantiate your transient beans.  Personally, I'd pass my Person bean to a validatePerson() method in the PersonService instead of calling validate() on the bean directly.  It will give you much flexibility in the term.

.pjf

Matthew said the following on 12/15/2009 09:25 PM:

--

Peter J. Farrell
Email: pe...@mach-ii.com | pjf@maestropublishing
Blog: The Harmonious Programmer
Twitter/Identi.ca: @maestrofjp

[Kurt Wiersma]

I agree with Peters solution however there is a way to use event-bean to get around this. You can use a listener call before the event-bean command to get a Person cfc from your service/ColdSpring setup and place it in the event object.

<notify listener="PersonListener" method="getPerson" resultArg="person" />

<event-bean name="person" type="foo.person" reinit="false" />

Notice the use of reinit=false and the user of the resultArg in the notify command. This will tell Mach II to use the instance of the person object that is in the event object before populating the bean. You can also use the new call-method command in 1.8 to directly call your service layer instead of using the notify command.

--Kurt

--
You received this message because you are subscribed to Mach-II for CFML list.
To post to this group, send email to mach-ii-for...@googlegroups.com
To unsubscribe from this group, send email to mach-ii-for-coldf...@googlegroups.com
For more options, visit this group at http://groups.google.com/group/mach-ii-for-coldfusion?hl=en
SVN: http://greatbiztoolsllc.svn.cvsdude.com/mach-ii/
Wiki / Documentation / Tickets: http://greatbiztoolsllc.trac.cvsdude.com/mach-ii/

[Matthew]

Hi Peter and Kurt

Thanks for the responses. I should have explained that I am
refactoring some business objects to be more intelligent i.e. fat-bean/
thin-service VS thin-bean/fat-service. I thought more people where
moving in this direction (Kurt / Peter it sounds like you guys
haven't). Up until now I have taken the approach of having my beans
pretty much be just data holders with getters / setters and then the
service layer does the rest ("thin bean / fat service concept). This
has worked well for me to date but I've recently created one object
where I think it should be able to validate itself (I am completely
changing the way I process form validation, persistence etc). The
object is what I call a formProfile object (there will be 1 per form).
In brief: the form submits to M2, which populates the appropriate
formProfile bean with everything set to strings. The bonus is that I
can poke the formProfile bean into the Session scope so when the form
is displayed again I can populate it easily. So now I'm at the point
where I want it to be validated. It makes sense that the formProfile
object should validate itself and return an array of errors if found.
I could do this validation in the Service layer but it just doesn't
make sense. I guess I'm still on the fence with fat-bean/thin-service
VS thin-bean/fat-service. Perhaps a mix of the 2 is acceptable as
well?

@Peter: I was reading this post (http://www.web-relevant.com/blogs/
cfobjective/index.cfm?mode=entry&entry=CC41749D-BDB9-5320-
E6CB3B1A3AA11799) and notice you were advocating thin-bean/fat-service
back in 2006. Also in another recent post (http://groups.google.com/
group/mach-ii-for-coldfusion/browse_thread/thread/d156ebb48ee378cd) on
the M2 forum you mentioned similar practice. So I assume you still
find this the best solution for you?

@Kurt: do you follow the thin-bean/fat-service pattern?

Cheers
Matthew

> > [image: The Harmonious Programmer]<http://feeds.feedburner.com/%7Er/TheHarmoniousProgrammer/%7E6/1>
>
> > *Peter J. Farrell*
> > Email: pe...@mach-ii.com | pjf@maestropublishing
> > Blog: The Harmonious Programmer <http://blog.maestropublishing.com>

> > Twitter/Identi.ca: @maestrofjp
>
> > --
> > You received this message because you are subscribed to Mach-II for CFML
> > list.
> > To post to this group, send email to
> > mach-ii-for...@googlegroups.com
> > To unsubscribe from this group, send email to
> > mach-ii-for-coldf...@googlegroups.com
> > For more options, visit this group at
> >http://groups.google.com/group/mach-ii-for-coldfusion?hl=en
> > SVN:http://greatbiztoolsllc.svn.cvsdude.com/mach-ii/
> > Wiki / Documentation / Tickets:
> >http://greatbiztoolsllc.trac.cvsdude.com/mach-ii/
>
>
>

>  TheHarmoniousProgrammer.1.gif
> 64KViewDownload

[Peter J. Farrell]

I wouldn't necessary say I opt for anemic domain models (aka dumb/thin beans).  A lot of my beans have certain logic methods to do complex things.  I hate to use an old example, but a Cart should be able to tally sub totals from the Item(s) the Cart contains by calling getSubTotal() on the Cart directly.  A truly dumb bean would be getters/setters (glorified "struct") and you'd pass in the Cart to some service object to get the sub totals.

The real question is it the bean's concern to do the validation internally?  In all honesty, I have some older applications where there is a mix of both validation in the service layer (or validation framework) and some beans that could validate themselves.  Depending on the complexity of your application, we've found internal validation methods to become easily mucked up because there are times in your application where you have two ways you want to validate the bean (i.e. multiple validation contexts).  In regards to self-validating beans, there are a few questions that I always kept asking myself:

* Do you break the mold and have validateA() and validateB() and loose the standard validate() method when you have multiple validation contexts?

* Do you keep the validate() method and have arguments you can pass in that changes the validate instead?  This gets messy because then you end up with basically a big switch/case in your validate() method do the correct "private" validation method can be calling internally in the bean.  Personally, this smells bad to just keep a convention going.

* What do you do about complex validations that require external singleton objects such as DB calls or external services (such as API calls to third-party vendor)?  Do you inject them or do you break encapsulation and refer to an external scope (i.e. application scope)?  Things like certainly make for the initialization of beans more complex over time.  This could be as simple as UDFs you need for validation.

* What about beans that have composition?  When you call validate() on your User object does it also call validate() on all the Address beans you have in array in your User?  Again, this is the multiple validation contexts problem where you want to validate some, all or none of other beans in another via composition.

* What if you have a bean that models something pretty complex?  Say you break data gathering phase of the bean over multiple steps?  It is common to have multi-step processes (step 1, step 2, step 3, finish, etc.).  You don't want to have the person to get to step 3 to find out there is a mistake on step 1, right?  Again, this breaks the validation context into multiple phases.  Are you going to have validateStep1(), validateStep2(), etc.?  I've done this in the past, but I shy away from this in the past year or so.

Over time, I've felt that self-validating beans loose there initial "sexiness" as applications grow in size and complexity based on these questions I posed above.  I'm sure there are times where an internal validate() method makes perfect sense for an application (in the past this was the case for some of my apps).  However, I've never worked on an application where it got smaller over time -- applications *always* grow.  Nowadays, I think about the validation context instead...

In general, I've seen a larger push in frameworks in other languages to "de-couple" the validation process from the target bean.  Spring (Java) for example you build validation objects in which you pass in the bean to validate and you get back an "exceptions" like handler object with the "problems".  One of the reasons Team Mach-II has a validation package (framework) on the docket for Mach-II Integrity (1.9).  This exact issue is something that Kurt and I specifically have spent a lot of time discussing in the month (we started discussing this in January 2009).

The one thing I would look at is the new form tag library and the new inner-bean functionality for the event-bean command.  You'll see it's pretty much driven off of beans (other non-CFML fameworks like Spring do this similarly).  Remember that all form data is strings and CFML is dynamic anyways -- you don't gain much to make birthDate to a type of "date" other than a bunch of headache.  I just embrace the dynamic nature of CFML and set beans properties to strings if they are edited by users. I do leave things like ids to numeric if they always passed as hidden, etc.  Using datatypes like "date", "UUID", etc. in forms in general is just false sense of security (and causes headaches as you even hint as by having string for your FormProfile object).  It's a rule in the apps I work on at work to **rely on the validation to ensure data integrity** instead of simple datatype enforcement at the language level.  For example, "numeric" does see if it's just a pure integer or a decimal.  It doesn't check to see if it's greater than 0 or less than 100.  Not that I recommend leaving off the "type" altogether (it's great doco for API level stuff and can stop some bone-head mistakes -- I just don't apply it much when it comes to forms).

All in all, there is no "wrong" way or no "right" way.  Some of software design comes down to personal experience and your own biases.  Again, it depends where you draw the line in the sand where thin/fat beans start and begin...  I try not to think about that line -- more about what works for me, other developers on the project and what *works* for *this* application.  You might just take the time to explore and realize that 1 year from now you'll change everything again ;-)

Best,
.Peter

P.s.  The one thing I think most developers would agree on is that ColdSpring is not best place to get transient beans created for you.  ColdSpring is slow for non-singletons transient beans -- it's like using a chainsaw to chop parsley for dinner.

Matthew said the following on 12/16/2009 04:57 PM:

Peter J. Farrell

Email: pe...@mach-ii.com | pjf@maestropublishing
Blog: The Harmonious Programmer

Twitter/Identi.ca: @maestrofjp

[Matthew]

@Peter. Thanks a million for taking the time and providing a detailed
response. As you can tell I'm revisiting the way I do things as well
as exploring new solutions. I love this comment "You might just take

the time to explore and realize that 1 year from now you'll change

everything again"... so true :)

It's great to hear about the journey you've been through and the
variations and reasons why you've found some things to work and others
to not work. I guess it boils down to what everyone keeps saying "it
depends". I guess every app requires different solutions and sometimes
even within the same app you may need to use a mix of solutions.

Thanks again for the response, great food for thought.

Cheers
Matthew

> ...
>
> read more »

[Kurt Wiersma]

I agree with what Peter. I have found that as my apps get more complex
I usually end up needing more information for validation other then
what is inside say a Person object. I often need to know what type of
Person it is and prehaps what type of validation I am doing (ie
creating a new person from a public web form vs. creating a new person
in the admin interface).

To me the cool thing is that you can handle both ways inside the Mach
II framework. You don't have to follow what Peter and I are
recommending due to how we setup the event-bean command.

--Kurt