I have another idea, see what you guys think.

Since the NoSQL DB driver I'm using is returning me a Struct for a doc (most
of them do), could I have just write a proxy that wraps the struct, and add
behaviors on it? instead of decompose the Struct into properties of a bean?

The pro is that I don't really need a DAO per Bean, but I'll need to write
some smart getter/setter's or implement a smart onMissingMethod.  And when I
need to attach some special property for some particular instances, I can
just do so and attach to the struct.

What do you think?

Thx,
Henry


On Fri, Jan 7, 2011 at 11:54 AM, Peter Bell <[email protected]> wrote:

>
> On Jan 7, 2011, at 2:43 PM, Henry Ho wrote:
>
> Yes, I get that, but with the DAO/Service/Bean approach, it seems like I
>> have more layers needed to be changed.  I'm just exploring if there're any
>> other lighter/more flexible approach to this.
>
>
> I don't think there is anything wrong with having a DAO, Service and Bean,
> but there shouldn't be any real duplication of metadata between them. There
> should be a single authoritative source of any piece of data in your app. So
> you need to pick one place to tell your system what properties a given
> object has.
>
> IMO, if you need to edit more than one thing when you add a property to an
> object, you're doing it wrong. I always have a single place with metadata
> describing my objects (either putting it into the object and using
> instantiation and reflection or having a metadata bean that I load into all
> of the objects relating to a given business object) and use that to control
> data access, the object itself and anything in the service class that needs
> to know about the business object. Where I can, I also use that
> representation to generate my DB schema if I have one (or to generate
> migrations) so I'm keeping things nice and DRY.
>
> Best Wishes,
> Peter
>
>  --
> You received this message because you are subscribed to the Google Groups
> "CFCDev" group.
> To post to this group, send email to [email protected].
> To unsubscribe from this group, send email to
> [email protected]<cfcdev%[email protected]>
> .
> For more options, visit this group at
> http://groups.google.com/group/cfcdev?hl=en.
>

-- 
You received this message because you are subscribed to the Google Groups 
"CFCDev" group.
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/cfcdev?hl=en.

Reply via email to