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 On Wed, Dec 16, 2009 at 7:02 PM, Matthew <[email protected]> wrote: > @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 > > On Dec 17, 11:03 am, "Peter J. Farrell" <[email protected]> wrote: >> 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: >> >> > 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 >> >> > On Dec 17, 3:29 am, Kurt Wiersma <[email protected]> wrote: >> >> >> 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 >> >> >> On Wed, Dec 16, 2009 at 2:21 AM, Peter J. Farrell <[email protected]> >> >> wrote: >> >> >>> 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: >> >> >>> 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 >> >> ... >> >> read more » > > -- > You received this message because you are subscribed to Mach-II for CFML list. > To post to this group, send email to [email protected] > To unsubscribe from this group, send email to > [email protected] > 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/ -- You received this message because you are subscribed to Mach-II for CFML list. To post to this group, send email to [email protected] To unsubscribe from this group, send email to [email protected] 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/
