cf.objective() 2007 : OO Architecture Back to Front

admin | May 6th, 2007 | conferences  

The selections for today’s session were kinda stale. I started with this session and only went to 2 others. Matt Woodward gave the talk and it was ok. He is a good presenter but he was introducing a very light-weight approach to architecture and didn’t mention anything regarding other options. Felt kinda one-sided but whatever. I finally learned how the ColdFusion community is using certain terminology in this session. A DAO is regarded as a proxy for datasource that returns single instances of domain objects. A Gateway (referring to the Table Gateway pattern) is used as a proxy for a datasource which returns multiple instances of a domain object but in query form. Exactly, wtf. There was no notion of a collection of objects anywhere, so that mark I gave the CF community yesterday, yeah … I take it back.

Overall, it wasn’t a great choice and I got a good survey written for the session so I said my peace. The other choices were Database Tuning and Hal Helms Large Scale Architectures, so the lesser of 3 evils I guess.



Tags: ,

Related posts

Discussion

  1. http://mpwoodward.myopenid.com/ Says:
    May 29th, 2007 at 10:04 am

    Thanks for the thoughts. Perhaps I should have prefaced my talk with “the following is my opinion” but I figured that was implicit given that I was the one presenting. I didn’t ever say that this was the one correct way to do everything, so my apologies if it came off that way. There are always multiple solutions to a problem.

    Since this is a theme in some of your other posts, I figured I better talk about the gateway pattern. I don’t always return a query from them, but in general it is more efficient. In my gateways when I *need* to deal with individual objects, I’ll likely have something like getUsers() that returns an array of objects, and getUsersAsQuery() when I would prefer a query object. The two don’t need to be mutually exclusive. I’m just unclear why you see returning a query object when A) that’s all you need, and B) it’s going to be far more efficient is such a cardinal sin.

    Clearly you have some strong opinions on these issues, so why not share them more by blogging about how you would approach things, writing an article for CFDJ, or better still, present at some CF conferences? As a community we’re all still wrapping our heads around OO in general as well as OO architecture, so we could all stand to learn a lot more from one another.

  2. admin Says:
    May 29th, 2007 at 7:41 pm

    Hey Matt,

    Thanks for leaving a comment on my blog. I didn’t know which post you wanted to keep so I left the latter of the two up.

    As far as your talk, like I said, I think you’re a good speaker, I just didn’t get much out of the talk. I’m probably not the most articulate blogger in the “sphere”, so most of what I say should be taken with a grain of salt. I write my blog for myself and my co-workers, I don’t intend for it to be community savy.

    To answer your question about the gateway pattern, I’m not adverse to using a query data structure in CF within my OO model. I believe in some cases it’s a large performance gain over using collections of objects. I do however believe that using it in its raw form is just as bad as trying to represent business objects using only collections of primitives (i.e. - structs rather than CFCs). For example, I think that queries should be used somewhat directly in your OO model when speaking about reporting. The overhead in abstracting access to the query data structure via a CFC is virtually nothing and it allows you to begin thinking about an interface (not necessarily, a programmatic one) between your classes. Reports become objects as well and can more closely emulate the problem your software, as a solution is trying to solve. This is probably not the detail you’re looking for, but we can talk more about it if you’d be interested. I’m not a genius when it comes to OO design, but I enjoy talking about and working with it.

    Thanks for the feedback.

Add A Comment