Csla object vs moving a light entity? Am I missing the obvious?

brix posted on Saturday, July 05, 2008

Guys,
I have always been intrigued by CSLA.
The book and the framework has been to me a great eye opener.

I might miss the obvious but how can a CSLA object be good if when you serialize it you move a heavy object about?

Am I totally missing something?

I have learnt in these years that when moving stuff around "keep it light"So the approach I am taking is to have a light Object (entity) moving around and a full blown object (bizObject) in the business layer.

This is the approach I have taken
Let's take my typical object "Customer"

I have 2 Assemblies.
MyCompany.Customer (Full Blown business Object here I usual have all the business logic related to customer)

MyCompany.Customer.Entities
 CustomerInfo (this is a light version with only getters and setters) travels around the Layers/Tiers.

We all know that validation should occur in all layers.You cannot leave your UI without having validated your "form".But you dont want to do a "to and fro" to your business Server,you will kill the app in a distributed scenario.
 
I want to keep my CustomerInfo very light with not validation whatsoever,but I want to have all the validation in the CustomerBiz Object.

How do you achieve this in CSLA?

Most frameworks out there they all seems to have both An Entities assembly and BizObject assembly.Whilst CSLA combines this in one.

Confused? yes I am .

can you help?

 

robert_m replied on Saturday, July 05, 2008

Serialized CSLA objects are not that heavy as it may seem. When you serialize an object, you only serialize it's data, not the code (when you deploy a CSLA app in a distributed manner, you have to deploy your business logic assembly (and any other assemblies it depends on) on both the server and the client - so making the code available on both ends). So the size of serialized CSLA object is similar to the size of any "ligtht" object containing same data fields...

brix replied on Sunday, July 06, 2008

Thanks for your reply.

"When you serialize an object, you only serialize it's data, not the code"

Not sure I see this.Any example anywhere?Are marking it "notSerializeable" or...?Sorry for dumb question how do you do it?

"when you deploy a CSLA app in a distributed manner, you have to deploy your business logic assembly (and any other assemblies it depends on) on both the server and the client "

Are you saying that in a distribuited enviroment you deploy everything to both client and server?In that case you are actually never remoting(good thing) .

Is this what you meant?So your big heavy object is never remoting and therefore is light.So the secret is deployment really.Is this correct?

Unfortunately CSLA is becoming more and more complex as it supports so many technologies,and the learning curve to do it properly is HIGH.

thanks again

robert_m replied on Sunday, July 06, 2008

Well, yes. The code never moves around, just the data. The code is available on both ends because you deploy it on both ends. DataPortal takes object's data, serializes it, moves the serialized data from client to server (or from server to client) using one of the available channels (wcf, ws, remoting...), then creates a new instance of the same type on the destination, deserializes the data and loads this new instance with it. So the number and size of methods in the class don't affect the size of the data you have to move over the wire.

RockfordLhotka replied on Sunday, July 06, 2008

Look at it this way. Here's a DTO (light data transfer object):

public class MyStuff
{
  public int Id { get; set; }
  public string Name { get; set; }
}

That object has only one behavior: store strongly typed data. All your business logic must be elsewere.

And here's a CSLA .NET object:

public class MyStuff : BusinessBase<MyStuff>
{
  private int _id;
  // property decl here

  private string _name;
  // property decl here

  // other code here
}

I've only put in the parts that matter for this discussion - but obviously this object supports data binding, probably includes validation and business rules and authorization and has a standardized persistence mechanism.

If you serialize either object, all you are serializing are the object's data elements. Typically when serializing a DTO you use a serializer that copies public read-write property values, and when you serialize a business domain object you copy the object's fields. But notice that either way you are serializing an int and a string.

Now it is true that CSLA also serializes some other stuff, like the meta-state of the object (is it new, dirty, marked for deletion, etc). Obviously that is important data, and if your framework doesn't do that for you, you'll probably have to add it to the DTO:

public class MyStuff
{
  public int Id { get; set; }
  public string Name { get; set; }
  public bool IsNew { get; set; }
  public bool IsDirty { get; set; }
  public bool IsDeleted { get; set; }
}

Which gets you pretty close to what CSLA serializes.

The key thing to remember is that when you serialize an object all that happens is that the object's data is pulled out of the object and put into a byte stream. Whether the object has a lot of behaviors is not doesn't matter at all - only the data (properties or fields) matter.

brix replied on Monday, July 07, 2008

Thanks for your time in replying .What you are saying makes a lot of sense!.

Just for the avoidance of doubt (being thick here)sorry.

If you dont want to serialize something you mark "NotSerialized"Correct?All the rest gets serialized No?

Or do you have a special method that gets only the Fields and serializes only those.

 

Thanks again

RockfordLhotka replied on Monday, July 07, 2008