我在 Windows Form 和 Silverlight 环境中利用 CSLA 都没有问题。对于 95% 的业务用户用例，CSLA 带来了很多好处。
Mark's experience with CSLA seems to be quite outdated. Nearly every point he made is inaccurate. CSLA is for user's use-case scenarios. Especially data-binding to UI's.
1) Using the folder analogy is completely inappropriate. You can have a single business object act as both a parent and child if you so choose, just not the same instance of your business object. Lazy loading of children is completely supported as well.
2) The serialization overhead is no more than what RIA services does, as CSLA uses the DataContractSerializer to utlimately serialize objects. Additionally MobileFormatter has been updated to allow for custom serializers. Now binary is supported as well as the original xml. Ultimately it all still goes through the DataConstractSerializer.
3) You can create any kind of DataPortal replacement, including using JSON within your own custom DataPortal. And CSLA command objects support managed properties, so serialization works exactly the same way as business objects.
4) It's true there is no in-place merge, however, I've never found this to be a problem.
5) Subscribers never get serialized with the business object. If your DataPortal is only local, then the original object is sent(not serialized) and so any subscribers it has will naturally still be attached.
I have no problem leveraging CSLA in both Windows Form and Silverlight environments. For 95% of the business user use-cases CSLA brings a lot to the table.
I have a two years experience with CSLA. In fact, when I started our project I really did not want to write an entity framework from scratch, something that was done in all of my previous jobs.
So, I picked CSLA. As any entity framework, it has good and bad points. I will list a few of the bad ones, because the good ones are described in abundance on the CSLA related sites. So, the nays:
CSLA parent-child relationship does not support folder-file pattern, where files are children of the parent folder, but they are also independent entities. In CSLA, children are integral part of the parent, so you cannot, for instance, update/delete/add a single child without updating the whole object tree. Forget about lazy loading of children - no such thing. In short, if your data model represents a folder-file like structure - do not use CSLA. We had to twist CSLA arms to let it support this mode.
Huge overhead in terms of state. Define a business object with 3 properties. Now send it over wire using some http binding. Pay attention to what gets transmitted. I know XML is not the best serialization vehicle, but your 3 properties are translated to ~4KB of XML. What does it include? Business rules and field data manager state among others. Extremely bloated. We employ zip compression, but still this is very disturbing.
Silverlight does not have normal serialization engine, so CSLA comes with a Mobile serialization, which is good if there is nothing else. The thing is that there are other things - JSON and protocol buffers, but CSLA is incompatible with these techniques. And Mobile serialization, although it solves the problem, it is a real pain when it comes to commands, because there you have to implement it manually (unlike business objects, which support it automatically for each managed property). Remember CArchive from MFC of 10 years ago? This is it.
Saving an object does not merge the new state in-place, rather returns a new object. We had much problems in Silverlight with the fact that every save replaces the object tree. So, we had to override the CSLA default behavior and implement in-place save with all the associated complexity of merging new state with the old one.
You quickly loose control over what is actually transmitted on the wire. For example, here is something I have discovered while examining the CSLA source code. Serializing a business object also serializes all the serializable subscribers to its PropertyChanged and PropertyChanging events. So, when such an object is sent to the server, it carries along with it all the serializable subscribers to these events. From the mobile object philosophy this is fine - mobile object simply preserves its living environment across the application tiers. From the practical point of view I find this a disaster waiting to happen. Needless to say that I have disabled this feature right on the spot.
Looking back after 2 years working with CSLA I have came to a conclusion that many others already came to before - your server side objects just not the same as your client side. Trying to pretend they are yields a lot of grief later in the development. And this is probably the most important nay to CSLA. The concept of mobile objects seems right at first, but as the project grows and the server and client sides develop having the same object type on the server and client becomes more of a liability rather than advantage - the internet is full of discussions on the matter.
Bottom line - I would not have used CSLA if I had the same understanding as I do now back then when I have started the project. CSLA gives you much stuff out of the box and I like DataPortal concept very much, but I see that I could have done fine without them and be in a better place now.
发布评论
评论（3）
Mark 在 CSLA 方面的经验似乎已经相当过时了。他提出的几乎每一个观点都是不准确的。 CSLA 适用于用户的用例场景。特别是与 UI 的数据绑定。
1）使用文件夹类比是完全不合适的。如果您愿意，您可以让一个业务对象同时充当父对象和子对象，但不能是业务对象的同一实例。也完全支持子项的延迟加载。
2) 序列化开销并不比 RIA 服务多，因为 CSLA 使用 DataContractSerializer 最终序列化对象。此外，MobileFormatter 已更新为允许自定义序列化程序。现在支持二进制以及原始 xml。最终，这一切仍然通过 DataConstractSerializer。
3) 您可以创建任何类型的 DataPortal 替代品，包括在您自己的自定义 DataPortal 中使用 JSON。而且 CSLA 命令对象支持托管属性，因此序列化的工作方式与业务对象完全相同。
4）确实没有就地合并，但是，我从未发现这是一个问题。
5) 订阅者永远不会与业务对象一起序列化。如果您的 DataPortal 仅是本地的，则发送原始对象（未序列化），因此它拥有的任何订阅者自然仍将被附加。
我在 Windows Form 和 Silverlight 环境中利用 CSLA 都没有问题。对于 95% 的业务用户用例，CSLA 带来了很多好处。
Mark's experience with CSLA seems to be quite outdated. Nearly every point he made is inaccurate. CSLA is for user's use-case scenarios. Especially data-binding to UI's.
1) Using the folder analogy is completely inappropriate. You can have a single business object act as both a parent and child if you so choose, just not the same instance of your business object. Lazy loading of children is completely supported as well.
2) The serialization overhead is no more than what RIA services does, as CSLA uses the DataContractSerializer to utlimately serialize objects. Additionally MobileFormatter has been updated to allow for custom serializers. Now binary is supported as well as the original xml. Ultimately it all still goes through the DataConstractSerializer.
3) You can create any kind of DataPortal replacement, including using JSON within your own custom DataPortal. And CSLA command objects support managed properties, so serialization works exactly the same way as business objects.
4) It's true there is no in-place merge, however, I've never found this to be a problem.
5) Subscribers never get serialized with the business object. If your DataPortal is only local, then the original object is sent(not serialized) and so any subscribers it has will naturally still be attached.
I have no problem leveraging CSLA in both Windows Form and Silverlight environments. For 95% of the business user use-cases CSLA brings a lot to the table.
http://www.lhotka。 net/cslacvs/viewvc.cgi/core/trunk/Samples/NET/cs/ProjectTracker/Mvc3UI/是著名的MVC3部分CSLA ProjectTracker 示例。这可能是
值得学习的一个。
Rocky 本人在 2 天前检查了一项更改，所以这可能是最前沿的
您可以从作者本人那里获取 CSLA 示例。
以下是从 svn 提取代码的说明
http://www.lhotka.net/cslanet/Repository.aspx
http://www.lhotka.net/cslacvs/viewvc.cgi/core/trunk/Samples/NET/cs/ProjectTracker/Mvc3UI/ is the MVC3 Part of the famous CSLA ProjectTracker sample. This might be the
one to learn from.
Rocky himself checked a change in just 2 days ago, so this is probably as Cutting edge
as you can get for an CSLA sample, from the author himself.
Here are instructions on pulling code from svn
http://www.lhotka.net/cslanet/Repository.aspx
我的建议 - 不要使用 CSLA。我将引用我对 https://stackoverflow.com/questions/ 的回复1234/你参加过csla大师班吗？
My advice - do not use CSLA. I am going to quote my reply to https://stackoverflow.com/questions/1234/have-you-attended-the-csla-master-class: