Hi, we are developing windows form app using CSLA.net as BLL. The business objects are becoming more and more complex, e.g. n-level hierarchy. The performance is also decreasing. We used wsHttpBinding. The app is only used inside corporate. My question is: if we use another binging, e.g. nettcpbinding, will the performance become better?
Hi fredg,
I guess you are looking for faster ways to talk to the application server.
If you aren't using CSLA 4.5, there are 2 alternatives:
1) Use CSLA 4.5 as server communications are much much faster
2) For CSLA 4.3 use the binary formatter proxy host WcfBfProxyHost
WcfBfProxyHost is also available for other CSLA 4 releases. Hope that helps.
Thanks Tiago. Can CSLA 4.5/CSLA 4.3 be used on .net 4.0? We are using .net 4.0 for our app.
Version 4.3 only supports .NET 4. Version 4.5 supports .NET 4 and 4.5.
I would also make sure you're using compression.
I do not believe 4.3 is good enough in terms of the reduced size of objects w/ the new serialization mechanism. I mean to someday do a more thorough examination on this but my initial examination was that objects were indeed 80% smaller with the new formatter but before the new formatter, compression gives you 93-95%. So right now we're using 4.5 but still use compression.
So I could definitely suggest enabling compression if you haven't because it continues to make a lot of difference.
There are obviously other things that can be done in terms of caching/etc (leveraging isolated storage with Silverlight), but those start to get application specific.
Has anyone done a performance
comparison between CSLA 4.0 and 4.5?
Why is csla4.5 much faster?
It isn't version 4.5 that is faster, it is the use of the more efficient data portal configuration. In 4.5 that is by default. In 4 you have to enable it using the instructions in the change log document.
It isn't version 4.5 that is faster, it is the use of the more efficient data portal configuration. In 4.5 that is by default. In 4 you have to enable it using the instructions in the change log document.
Hi Rocky,
I'm under the impression that - on CSLA 4.3 - the CslaBinaryReader/Writer is available only for SIlverlight/Windows Phone. As fredg is working on a WindowsForms application, he can't use the CslaBinaryReader/Writer. To take advantage of the new serialization mechanism, the application must target CSLA 4.5. For a Windows Forms application, the code shouldn't need big changes (if any).
Thanks. We are developing on windows XP. i wonder if we can install and use CSLA 4.5 although it supports .NET 4.0?
Also, is there any instruction to convert CSLA 4.0 to 4.5 for a winForm app? How easy will it be?
Sorry, tiago is right - the new data portal feature is only available to non-.NET code in CSLA 4...
One thing about XP though - you do realize that Microsoft is ending all support for XP in April 2014? Windows XP is the OS most targeted by virus developers, and I shudder to think what will happen once Microsoft stops issuing patches and so forth. Anyone still running XP machines that are connected to the Internet is in for some serious trouble later in 2014...
So even if we upgrade to CSLA 4.5, our winForm app's performance cannot be incresed?
For win xp, that would be a long road for a corporate to upgrade. CSLA 4.5 can NOT be used on winXP?
CSLA 4.5 supports .NET 4.
I believe .NET 4 still runs on XP?
So you should be fine using CSLA 4.5 on XP.
So even if we upgrade to CSLA 4.5, our winForm app's performance cannot be incresed?
Under CSLA 4.5 all technologies (Windows Forms, WPF, Web, Silverlight, etc) use the new (and very fast) serialization algorithm. This is much faster than the binary formater. If that's not enough, on top of that you can add compression.
It is important to evaluate what you are trying to achieve with compression. On a typical LAN with 100 GB cards my vote would be not to use compression. It has overhead in terms of CPU and memory usage. My suggestion would be to analyze your code and see where the bottleneck is. New communication protocol is both faster and more memory efficient than the old one.
We found the bottleneck in our code. But we will definitely upgrade to new csla in future.
Copyright (c) Marimer LLC