I am working on improving the performance of our web hosted silverlight application. This is the application written in CSLA.NET for Silverlight. End user will access the website through internet, so we are trying to reduce the size of the message transferring between Silverlight client and Web Site.
On thing we found out, when fetching same amount data (same amount of row from same table), the size of message body created by CSLA Portal is at least 2 - 5 times larger than using standard WCF Service.
Yes, we are using IIS compression to compress message. But still compressed message body by CSLA Portal is much larger (2 - 5 times) than using standard WCF Service. Also, technically the time to process large message will be much longer than small message on both Silverlight client and Web Site.
Since this is a internet basd Silverlight application with potential thounsands of concurrent users, smaller message boday as well as quicker message processing will be appreciated.
E.g.,
CSLA Portal:
void DataPortal_Fetch() { using (MyEntities ctx = new MyEntities()) { RaiseListChangedEvents = false; IsReadOnly = false; var orders = ctx.Orders.ToList(); var readOnlyOrders = from order in orders select ReadOnlyOrder.GetOrder(order); this.AddRange(readOnlyOrders); IsReadOnly = true; RaiseListChangedEvents = true; } }
WCF Service:
public List<Order> GetOrders() { List<Order> orders = null; using (MyEntities ctx = new MyEntities()) { orders = ctx.Orders.ToList(); } return orders; }
You don't say what your "WCF Service" technology is, but I'm going to assume it's either L2S or EF, based on the code.
Given that, this is not an apples-to-apples comparison.
CSLA objects contain quite a bit more functionality than L2S or EF entities do, and as such will be sending quite a bit more information over the wire.
If message size is a great concern to you, you might consider switching to a more SOA-style infrastructure. In this case, you aren't sending CSLA objects over the wire - you're sending DTO's (or EF entities or whatever) over the wire, and creating your business objects on each side based on that data. Rocky's books (and e-books) talk about this. You trade message size with processing time (and a slightly more complicated codebase), but in your case I would think it's at least worth investigating.
HTH
- Scott
Csla is probably including some other meta data. remember its not just the data in the list, but GlobalContext and ClientContext gets transfered as well (ClientContext only from client to server though, not the other way around). if this data is important, you'll have to just accept that.
However you could change your Silverlight objects to call a Wcf service instead of using the mobile object pattern you're currently using. This will likely increase your maintance costs though, as you're now basically supporting two applications. one application is your silverlight client and silverlight bos, then your other application is the web service layer + dtos, behind that is your Csla objects and then your dal which the BOs use.
First, there is nothing stopping you from using CSLA to create the edge application that runs on the client, and to have it call a set of services. That is SOA, and it is a perfectly good architectural model - if a little expensive. That scenario is entirely supported by CSLA - that's what the local data portal exists in Silverlight.
In the end it is a business decision. You need to decide if the features and simplicity provided by the data portal (which translate to cheaper development/maintenance) are able to offset the difference in network bandwidth consumption. Or if the network bandwidth savings by using an SOA model offset the increased cost of development/maintenance of the app.
Now on to your question itself.
The primary reason for the difference is that CSLA requires that object graphs flow across the network with 100% fidelity. Normal services do not - they assume you have desigend your message graph so it lives within the limitations of service message standards. To clone an object graph with 100% fidelity, the object graph needs to contain type information, relative position information, inter-graph link information, etc.
If you try to send a normal object graph through a service, you'll get a different object graph on the other side. You'll lose some data, and duplicate other data. Obviously nobody does this, because it woudl break your app - so most people reshape their object graph to meet the requirements of the service standards (100% public read-write fields, no duplicate or lateral references in the object graph, no business logic in the classes, etc).
Or they use CSLA so the object graphs move over the network, retaining their non-public field values, multiple references within the graph, and business logic in the classes).
Copyright (c) Marimer LLC