0

我正在寻找一个完整的网络（基于CSLA 4.0的 MVC 或 WebForm 示例应用程序。有什么想法吗？我认为它的 ProjectTracker 示例只是 WinForm 并且基于 CSLA 的旧版本。

4

3 回答 3

7

Mark 在 CSLA 方面的经验似乎已经过时了。他提出的几乎每一个观点都是不准确的。CSLA 用于用户的用例场景。尤其是与 UI 的数据绑定。

1）使用文件夹类比是完全不合适的。如果您愿意，可以让单个业务对象同时充当父对象和子对象，而不是业务对象的同一个实例。孩子的延迟加载也是完全支持的。

2) 序列化开销不超过 RIA 服务所做的，因为 CSLA 使用 DataContractSerializer 来最终序列化对象。此外，MobileFormatter 已更新为允许自定义序列化程序。现在支持二进制以及原始 xml。最终，这一切仍然通过 DataConstractSerializer。

3) 您可以创建任何类型的 DataPortal 替换，包括在您自己的自定义 DataPortal 中使用 JSON。CSLA 命令对象支持托管属性，因此序列化的工作方式与业务对象完全相同。

4）确实没有就地合并，但是，我从来没有发现这是一个问题。

5) 订阅者永远不会被业务对象序列化。如果您的 DataPortal 只是本地的，那么原始对象将被发送（未序列化），因此它拥有的任何订阅者自然仍将被附加。

在 Windows 窗体和 Silverlight 环境中使用 CSLA 都没有问题。对于 95% 的业务用户用例，CSLA 带来了很多好处。

于 2012-05-07T08:29:16.047 回答
2

http://www.lhotka.net/cslacvs/viewvc.cgi/core/trunk/Samples/NET/cs/ProjectTracker/Mvc3UI/是著名的 CSLA ProjectTracker 示例的 MVC3 部分。这可能是一个值得学习的地方。

Rocky 本人仅在 2 天前检查了更改，因此这可能是作者本人从 CSLA 样本中获得的最前沿。

以下是从 svn 中提取代码的说明

http://www.lhotka.net/cslanet/Repository.aspx

于 2011-10-05T11:23:50.960 回答
0

我的建议 - 不要使用 CSLA。我将引用我对https://stackoverflow.com/questions/1234/have-you-attended-the-csla-master-class的回复：

我有两年的 CSLA 经验。事实上，当我开始我们的项目时，我真的不想从头开始编写实体框架，这是我以前所有工作中都做过的事情。

所以，我选择了 CSLA。作为任何实体框架，它都有优点和缺点。我将列出一些不好的，因为好的那些在 CSLA 相关网站上有大量的描述。所以，反对者：

  • CSLA 父子关系不支持文件夹-文件模式，其中文件是父文件夹的子级，但它们也是独立的实体。在 CSLA 中，子级是父级的组成部分，因此您不能在不更新整个对象树的情况下更新/删除/添加单个子级。忘记延迟加载孩子 - 没有这样的事情。简而言之，如果您的数据模型表示类似文件夹文件的结构 - 不要使用 CSLA。我们不得不扭动 CSLA 的手臂，让它支持这种模式。
  • 状态方面的巨大开销。定义具有 3 个属性的业务对象。现在使用一些 http 绑定通过网络发送它。注意传输的内容。我知道 XML 不是最好的序列化工具，但您的 3 个属性被转换为大约 4KB 的 XML。它包括什么？业务规则和现场数据管理器状态等。极度臃肿。我们采用 zip 压缩，但这仍然非常令人不安。
  • Silverlight 没有正常的序列化引擎，所以 CSLA 自带了一个 Mobile 序列化，如果没有其他的就好了。问题是还有其他东西——JSON 和协议缓冲区，但 CSLA 与这些技术不兼容。而移动序列化，虽然它解决了问题，但在涉及命令时确实很痛苦，因为您必须手动实现它（与业务对象不同，它为每个托管属性自动支持它）。还记得 10 年前 MFC 的 CArchive 吗？就是这个。
  • 保存对象不会就地合并新状态，而是返回一个新对象。我们在 Silverlight 中遇到了很多问题，因为每次保存都会替换对象树。因此，我们必须覆盖 CSLA 默认行为并实现就地保存，以及将新状态与旧状态合并的所有相关复杂性。
  • 您很快就会失去对网络上实际传输的内容的控制。例如，这是我在检查 CSLA 源代码时发现的。序列化业务对象还会序列化其 PropertyChanged 和 PropertyChanging 事件的所有可序列化订阅者。因此，当这样一个对象被发送到服务器时，它会携带所有这些事件的可序列化订阅者。从移动对象的理念来看，这很好——移动对象只是在应用程序层中保留其生存环境。从实际的角度来看，我发现这是一场等待发生的灾难。不用说我已经当场禁用了这个功能。
  • 在与 CSLA 合作 2 年后回首往事，我得出了许多其他人之前已经得出的结论 - 您的服务器端对象与您的客户端不同。试图假装他们是在开发后期产生了很多悲伤。这可能是对 CSLA 最重要的反对。移动对象的概念起初似乎是正确的，但随着项目的发展以及服务器和客户端的发展，在服务器和客户端上拥有相同的对象类型变得更多的是一种责任而不是优势——互联网上充斥着关于这个问题的讨论.

底线 - 如果我在开始项目时有与现在相同的理解，我不会使用 CSLA。CSLA 为您提供了很多开箱即用的东西，我非常喜欢 DataPortal 概念，但我发现如果没有它们，我本可以做得很好并且现在处于更好的位置。

这是我的 2 美分。

于 2012-04-30T15:04:28.023 回答