static fields and command objects

boo posted on Monday, March 12, 2007

We are slowly moving to CSLA, and as much as we'd like to stop in our tracks and just do it, we really can't - we're doing a little here and a little there.  One of the main problems in our move from a poorly designed system with way too many DTO's to CSLA has been a particular set of objects that can be 'converted' (and I use the term very loosely) to another type of object.  Now in the end these DTO's will go away all together - but we can't do it right now because the refactoring would be a nightmare...at this point.

Now to help ease the transition and still keep on track with business objectives we've created a command object which will obsolete several chunks of code that will ultimately lead to the removal of several DTO's.  This command object is used more as a utility than a command object and is publicly exposed, which again, not the command object 'role' as I understand it, but it works well for our purposes in the meantime.

Now to the point, the command object has to do several look-ups across many tables to do it's 'thing'.  I want to use static fields to cache some of this information (because it's not all that much (to the app server which is memory rich) but the command object is called many times and there are many tables hit), but in a remoting scenerio I don't want to be serializing these fields down to the client machine (which doesn't have memory to use for objects that aren't used on the client) and back again because they're only needed on the application server - this would also be extra traffic on the network for no reason.  Now I know there is RunLocal() for running things only on the client; is there an attribute to mark a field (or property) as ServerOnly() or something to that effect so that I can prevent transferring all this extra data down to the client which it will never use on client side?  And again, in the end this command object won't exist, it's just a bridge to get us from point A to point B until we get to point Z (total CSLA architecture).

Thanks!

ajj3085 replied on Tuesday, March 13, 2007

Boo,

Is your concern about serializing related to the static fields?    The static fields don't get serialized to and from the DP, and as long as you access them only in the DP methods, only the server will use the memory (if you don't want the memory used on the client).

Does that help at all?

Andy

boo replied on Tuesday, March 13, 2007

I don't understand. 

If the serializer serializes everything about an object why wouldn't it serialize the static fields?  I know the serializer will serialize instance fields otherwise the business properties wouldn't be accessible on the client...so does Rocky have something to ignore serialization of static fields?  Would the same hold true if there was a public property the client could read that accessed a static field?  Granted I don't see why you would do that, but just asking.

xal replied on Wednesday, March 14, 2007

Binary serialization won't care for the properties in your object, so no, that won't make any difference.

It ignores static fields because they aren't really part of the object, they're defined at the type level.
In other words, static fields are not part of the object's state, they're part of the type's state.

Andrés

ajj3085 replied on Wednesday, March 14, 2007

[deleted]