Great question. There are no hard and fast rules with this. But, I think the side effects of doing this are what you want to concentrate on when thinking about this. The primary issue you're going to have is whether or not your VOs go across process boundaries (server, database, etc). Once objects are leaving your process and are operated on by outside software you have to keep track of object identity. Most VOs have object identity defined by an external ID (auto increment ID field in your database, UUID, etc). Why is this important? Well once objects start leaving your process you're going to have more than one instance of the same business object in memory at a time (think two User objects with the email [email protected] same external ID). If var A : User and var B : User both have A.id == B.id they are the same business object, however A === B is NOT true.
Using instance ID is no longer good enough to relate objects together. You have to start using that external ID to figure out if two instances are really the same logical business object. By using the external ID to identify it you can match up objects internally in your program with objects coming from the outside that are just copies of it. Why is this important? If you are creating bindings on your VO objects then these copies can not be substituted for the original. Why? Because the UI has registered listeners onto that original instance, and swapping that instance for one of those copies won't work. If you change the copy instead of the original the UI won't reflect that change because the copy doesn't have those listeners registered on it. That means you have to build a framework to take objects from the server and merge them with the instances you have in memory. Merging data is NOT trivial, and no framework out there will aid in making this task easy. Sure it's easy when you have an object with scalar values, but then you get a collection of something and bam it just got nasty. It's much easier if you can just say "Here's a new object from the server, toss my copy, and use it." There are some fancy things you could do with Interfaces, and wrapping objects (again that means more clever architecture - ala bridge pattern). Furthermore, it makes it difficult to have only portions of your program in memory. If the number of VOs are very large you might want to only load portions of your model into memory. With listeners in the picture you'll have to unregister listeners to get them out of memory. You might be able to do some fancy things with weak references, but this doesn't always work. Especially if your UI doesn't go out of scope when your objects do. One way around this is to only have listeners on a smaller set of VO objects that you keep in memory. Then they can be proxied listeners for the children. They can fire off events for the children without needing register events on the children. This will work, but binding onto the children would not work. In the past I've found that it's easier to keep listening out of VOs because of these issues. Remember going out of the process includes going to the local AIR database or a remote server. If your program is small you might be able to get away with it for a while, but if your program is popular you're going to run into problems as you need to scale up in data sizes. Charlie On Fri, Jan 22, 2010 at 2:45 PM, John Mason <[email protected]> wrote: > So having a discussion at lunch and figure I post this to the user group to > see what people think. > > I'm working on a AIR app that uses the Mate framework. The pattern has > value objects (VOs, also sometimes called data transfer objects). The VOs > have binding turn on at the class level. I didn't really think about it > until recently that I suspect those bindings weren't even needed in this > particular case, but I was also wondering if this was just a bad design > pattern to begin with. Should a VO even be allowed to fire off binding > events? > > Thoughts? > > John > [email protected] > > > > > ------------------------------------------------------------- > To unsubscribe from this list, simply email the list with unsubscribe in > the subject line > > For more info, see http://www.affug.com > Archive @ http://www.mail-archive.com/discussion%40affug.com/ > List hosted by http://www.fusionlink.com > ------------------------------------------------------------- > > >
