Leon, See inline.
> Aehm... Sorry for my incompetence, but what is a VO-model? Value Object model, sometimes referred to as DTO (Data Transfer Object). > As for the question, I'd expect a null object reference to be 24 bit, which > should be smaller than most primitives. That's useful info. How do you know this? I just want some way to verify this. > Other question, why don't you develop an object hierarchy, where each > subobject in the hierarchy contains exactly the information for a particular > screen? We did this for a project before this one and it was a bit of a nightmare. With over 40 screens that display different but similar information. Yes, I know what you are thinking: inheritance. Unfortunately, it doesn't work as well as it sounds. We ended up some tons and tons of VOs. Some we had to name FacilitySummaryVo, just to differentiate it from the full blown FacilityVo. It got messy and not very OO at all. We were thinking that a much cleaner model would be to model real world objects, not screens. This way, the entire dev team can share the same objects. Less maintenance, less CM footprint, must more manageable. Thanks, Yaakov. > > Regards > Leon > > > -----Ursprüngliche Nachricht----- > > Von: Yaakov Chaikin [mailto:[EMAIL PROTECTED] > > Gesendet: Sonntag, 19. Juni 2005 20:11 > > An: Struts Users Mailing List > > Betreff: Re: [OT] Serializing object with null pointers (performance?) > > > > Well, the point we were shooting for on this project is to go > > away from the "per screen" Vo structure and move to > > "domain/business model Vo structure." Primitive vs Object is > > really a side point. Since we are not custom coding a Vo per > > a particular screen, we don't to carry around ANY values for > > fields we don't need for particular screen, so that's why the > > Object vs primitive. > > > > Does it take the same amount of space "on the wire" to > > serialize a null pointer as a primitive? We are not as > > concerned for the time it takes to serialize the object as > > for the space on the wire. > > > > Thanks, > > Yaakov. > > > > On 6/19/05, Laurie Harper <[EMAIL PROTECTED]> wrote: > > > I would expect the performance of serializing a null object > > reference > > > to be trivially different than serializing a primitive > > value. In fact > > > it may be slightly worse due to the overhead of writeObject(). > > > > > > Unless you're doing a hell of a lot of serialization and > > profiling has > > > shown that it's causing a performance bottleneck I wouldn't > > touch what > > > you have. > > > > > > L. > > > > > > Yaakov Chaikin wrote: > > > > Hi all, > > > > > > > > I have the following situation. I have a Vo model that is > > in essence > > > > a domain/business object model. Of course, a particular screen > > > > doesn't need the entire model to be loaded with data. So, > > what I was > > > > thinking is > > > > 1) Make all class variables objects (as opposed to > > primitives, most > > > > are objects anyway) > > > > 2) Make all class variables NULL, unless I need it for a > > particular screen. > > > > > > > > This way, I won't have to carry data around the wire that > > I don't need. > > > > > > > > The question I have is this. What performance hit, if > > any, do I get > > > > by passing around an object with null pointers in it? How do they > > > > get serialized? > > > > > > > > Is this a good idea in general or am I just imagining > > that passing > > > > around null pointers saves me "THAT MUCH"? > > > > > > > > Thanks, > > > > Yaakov. > > > > > > > > > > > --------------------------------------------------------------------- > > > To unsubscribe, e-mail: [EMAIL PROTECTED] > > > For additional commands, e-mail: [EMAIL PROTECTED] > > > > > > > > > > --------------------------------------------------------------------- > > To unsubscribe, e-mail: [EMAIL PROTECTED] > > For additional commands, e-mail: [EMAIL PROTECTED] > > > > > > > > --------------------------------------------------------------------- > To unsubscribe, e-mail: [EMAIL PROTECTED] > For additional commands, e-mail: [EMAIL PROTECTED] > > --------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
