有人有 CSLA 的实际经验吗？

StackOverflow https://stackoverflow.com/questions/15241

  •  08-06-2019
  •  | 
  •  

题

我公司的主要 Web 应用程序迫切需要一组漂亮的库，以使其以某种方式可维护和可扩展，我的一位同事建议使用 CSLA。所以我买了这本书，但是：

程序员不再看书了

我想了解 SOFlow 社区对此的看法。

这是我的问题：

  1. 人们如何使用 CSLA？
  2. 优缺点都有什么？
  3. CSLA 真的不适合 TDD 吗？
  4. 我有什么选择？
  5. 如果您已经停止使用它或决定不使用它，为什么？
有帮助吗？

解决方案

在具体回答你的问题之前，我想先说几点想法。CSLA 适合您的项目吗？这取决于。我个人认为 CSLA 适用于基于桌面的应用程序，这些应用程序不将单元测试视为高优先级。如果您想轻松扩展到 n 层应用程序，CSLA 非常有用。CSLA 往往会受到一些批评，因为它不允许纯粹的单元测试。这是事实，但是就像技术中的任何事物一样，我相信存在 没有一种正确的方法. 。单元测试可能不是您针对特定项目进行的事情。适用于一个团队和一个项目的方法可能不适用于另一团队或其他项目。

对于CSLA也存在很多误解。它不是一个 ORM。它不是 NHibernate 的竞争对手（事实上，使用 CLSA Business Objects 和 NHibernate 因为数据访问非常适合）。它形式化了一个概念 移动对象.

1.有多少人在使用 CSLA？
基于 CSLA 论坛, ，我想说有相当多的基于 CSLA 的项目。老实说，我不知道有多少人真正在使用它。我过去在两个项目中使用过它。

2.优缺点都有什么？
虽然很难用简短的列表来概括，但以下是我想到的一些优点/缺点。
优点：

  • 让新开发人员提高速度很容易。CSLA书籍和示例应用程序是提高速度的绝佳资源。
  • 验证框架确实是世界一流的，并且已被许多其他非 CSLA 项目和技术“借用”。
  • 业务对象中的 n 级撤消
  • 配置行更改以实现 n 层可扩展性（注意：甚至不需要重新编译）
  • 关键技术是从“真实”代码中抽象出来的。当引入WCF时，它对CSLA代码的影响很小。
  • 可以在 Windows 和 Web 项目之间共享您的业务对象。
  • CSLA推动常态化 行为 而不是正常化 数据 （离开数据库进行数据标准化）。

缺点：

  • 单元测试困难
  • 缺乏关注点分离（通常您的业务对象内部有数据访问代码）。
  • 随着CSLA推动常态化 行为, ，而不是标准化 数据, ，这可能会导致业务对象名称相似，但用途不同。这可能会导致一些混乱，并让人感觉您没有适当地重用对象。也就是说，一旦实现了生理上的飞跃，它就更有意义了——用“旧”的方式来构造物体似乎是不合适的。
  • 以这种方式构建应用程序并不“流行”。您可能很难找到对该技术充满热情的开发人员。

3.读完这篇文章后，CSLA 真的不适合 TDD 吗？
我还没有找到使用 CSLA 进行 TDD 的有效方法。也就是说，我确信有很多比我更聪明的人可能已经尝试过并取得了更大的成功。

4.我有什么选择？
领域驱动设计目前正受到大力推动（这是理所当然的——它对于某些应用程序来说非常棒）。由于 LINQ（以及 LINQ to SQL、Entity Framework 等）的引入，还开发出了许多有趣的模式。福勒书 POAA, ，详细介绍了许多可能适合您的应用的模式。请注意，某些模式是竞争的（即Active Record 和 Repository），因此旨在用于特定场景。虽然 CSLA 并不完全匹配该书中描述的任何模式，但它与 Active Record 最相似（尽管我觉得声称与该模式完全匹配是短视的）。

5.如果您已经停止使用它或决定不使用它，为什么？
对于我的上一个项目，我没有完全推荐 CSLA，因为我认为应用程序的范围对于 CSLA 提供的好处来说太大了。
我会 不是 在 Web 项目上使用 CSLA。我认为还有其他技术更适合在该环境中构建应用程序。

总而言之，虽然 CSLA 绝不是 银子弹, ，适合某些场景。

希望这可以帮助！

其他提示

阅读完所有答案后，我发现不少人对 CSLA 存在一些误解。

第一的， CSLA 不是 ORM. 。我怎么能这么肯定地说呢？因为罗克福德·洛特卡（Rockford Lhotka）自己在接受采访时多次说过这样的话 .NET 摇滚 和 汉塞尔分钟 播客。寻找 任何 洛基接受采访的那一集，他会毫不含糊地陈述这一点。我认为这是人们需要理解的最关键的事实，因为几乎所有关于 CSLA 的误解都源于相信它是一种 ORM 或试图将其用作一种 ORM。

正如 Brad Leach 在他的回答中提到的那样，CSLA 对象对行为进行建模，尽管更准确的说法是它们对数据的行为进行建模，因为数据是它们不可或缺的一部分。CSLA 不是 ORM，因为它完全不知道您如何与数据存储交互。你 应该 使用某种具有 CSLA 的数据访问层，甚至可能是 ORM。（我愿意。我现在使用实体框架，它工作得很好。）

现在，进行单元测试。我在对 CSLA 对象进行单元测试时从未遇到过任何困难，因为我不会将数据访问代码直接放入业务对象中。相反，我使用存储库模式的一些变体。 该存储库由 CSLA 使用，而不是相反。 通过交换我的单元测试的假存储库并使用本地数据门户， 繁荣！ 这很简单。（一旦实体框架允许使用 POCO，这将更加干净。）

所有这一切都源于认识到 CSLA 不是 ORM。它可能会消耗一个 ORM，但它本身并不是一个。

干杯。

更新

我想我应该再发表一些评论。

有人说，与 LINQ to SQL 等相比，CSLA 过于冗长。但在这里我们将苹果与橙子进行比较。LINQ to SQL 是一种 ORM。它提供了一些 CSLA 没有的东西，而 CSLA 提供了一些 L2S 没有的东西，比如集成验证和 n通过各种远程数据门户进行层持久性。事实上，我想说最后一件事， n对我来说，坚持不懈胜过一切。如果我想通过网络使用实体框架或 LINQ to SQL，我必须在两者之间放置类似 WCF 的东西，这会极大地增加工作量和复杂性，以至于我认为这是 很多 比 CSLA 更详细。（现在，我是 WCF、REST 和 SOA 的粉丝，但是在您真正需要的地方使用它，例如当您想要向第三方公开服务时。对于大多数业务线应用程序来说，它并不是真正需要的，CSLA 是更好的选择。）事实上，通过最新版本的 CSLA，Rocky 提供了 WCFDataPortal, ，我用过。效果很好。

我是以下的粉丝 坚硬的, 、TDD 和其他现代软件开发原则，并在可行的地方使用它们。但我认为 CSLA 的好处超过了那些正统观点的一些反对意见，并且无论如何，我已经设法使 CSLA 与 TDD 配合得很好（并且很容易），所以这不是问题。

是的，我（嗯，我们）广泛使用它来建模我们的业务流程逻辑，该逻辑主要是 Windows 表单应用程序中的数据绑定表单。该应用程序是一个交易系统。CSLA 被设计为位于 UI 下方的该层。

如果您考虑标准的复杂业务线应用程序，您可能有一个包含许多字段的表单，这些字段的许多规则（包括跨字段验证规则），您可以调用模式对话框来编辑某些子对象，您可以希望能够取消此类对话框并恢复到以前的状态。CSLA 支持这一点。

它的缺点是它有一点学习曲线。

要记住的关键一点是使用 CSLA 来建模 用户 与某些应用程序上的表单交互。对我来说最有效的方法是在构建 CSLA 对象之前设计 UI 并了解它的流程、行为和验证规则。不要让 CSLA 对象驱动 UI 设计。

我们还发现能够使用 CSLA 业务对象服务器端来验证从客户端发送的对象非常有用。

我们还内置了针对 Web 服务异步执行验证的机制（即根据主方检查交易对手的信用额度范围）。

CSLA 在 UI、业务逻辑和持久性之间强制实施严格分离，我们针对它们编写了大量单元测试。它可能不是严格的 TDD，因为您是通过 UI 设计来驱动它的，但这并不意味着它不可测试。

唯一真正的替代方案是创建您自己的模型 \ 业务对象，但很快您最终就会实现 CSLA 提供的开箱即用的功能（INotifyPropertyChanged、IDataErrorInfo、PushState、PopState 等）

我在一个项目中使用了 CSLA，它效果很好，让事情变得更加简单和整洁。

我们知道有一个共同的标准来工作，而不是让您的团队以自己不同的个人风格编写业务对象。

//安迪

几年前我就有过这方面的经验。它是一个出色的架构，但非常复杂，难以理解或更改，并且它解决了我们大多数开发基于 Web 的应用程序不一定会遇到的问题。它更多地是为基于 Windows 的应用程序和处理多级撤消而开发的，特别强调事务逻辑。您可能会听到人们说，由于 Web 应用程序是页面级别的请求-响应，所以这是不合适的，但对于 AJAX 风格的 Web 应用程序来说，这个论点可能站不住脚。

它有一个非常深入的对象模型，你可能需要一段时间才能真正理解它。当然，几年之内可能会发生很多变化。我有兴趣听到其他最近的意见。

综合考虑，它不会是我建筑的第一选择。

为了捍卫 CSLA，尽管我确实同意许多评论，特别是单元测试评论……

我的公司广泛将其用于 Windows 窗体数据输入应用程序，并取得了很大的成功。

  • 它提供了开箱即用的功能，而我们没有时间或专业知识来自己编写。
  • 它标准化了我们所有的业务对象，使维护变得容易，并减少了新开发人员的学习曲线。

总的来说，我想说，它所带来的任何问题都远远超过了它带来的好处。

更新：除此之外，我们仍在将它用于我们的 Windows 窗体应用程序，但将它用于其他应用程序（例如网站）的实验表明，当您不需要它的太多功能时，它可能会很麻烦，我们现在正在研究更轻量级这些场景的选项。

我加入了一个强制执行 CSLA 的团队。我们不使用远程数据门户，这是我同意使用该框架的唯一原因。我从来没有接受过 CSLA 的想法，所以也许这就是为什么我对它只有一些问题，抱歉。

有几个问题：

我不需要在我的代码和 .NET 框架之间设置路障，这正是这个框架给我的感觉。我对列表对象的选择有限，而我只能忽略 .NET 框架中丰富的列表对象。

这是完全荒谬的，我们有这些只读列表，然后是非只读列表。因此，如果我必须向列表中添加一个项目，我就必须重新创建整个列表......你是认真的吗？

然后 csla 想要管理我的对象状态，这很好，但没有真正暴露任何东西。有时我想手动更改对象状态，而不是再次获取它，这似乎是 csla 希望我做的。我基本上最终创建了许多属性来公开 csla 认为我不应该直接访问的选项。

为什么我不能实例化一个对象？我们最终创建了静态方法来实例化一个对象并将其传回......你在开玩笑吗？

检查框架源代码，在我看来，反射代码看起来很重。

使用csla的理由：

  • 直接的 .net 框架对你来说太强大了。

  • 如果你的开发人员经验不足，无法掌握模式的概念，那么 csla 几乎会让每个人都达成共识。

    1. 我不需要在我的代码和 .NET 框架之间设置障碍...我被这些列表对象困住了。

我们开始使用 CSLA 是因为我们认为它会对我们的模型层有所帮助。有点矫枉过正，我们现在使用的主要是 SmartDate 类，只是因为我们已经链接到该库。

我们认为验证接口确实可以帮助我们执行业务规则，但它不能很好地与 WCF 和序列化配合使用（我们仍然停留在版本 2.0.3.0 上，因此情况可能已经发生了变化）。

不要只考虑 CSLA 的列表，但在使用它之前，研究一下它的好处并确保它们确实适用。您的团队能够正确/一致地实施它吗？需要远程和门户舞蹈吗？

我认为除了所有的理论思考之外，这都是关于遵循基本的经过验证的模式的干净/可维护/可扩展/可测试的代码。

我计算了从 CSLA 转换的项目的特定域中所需的代码行数。在所有不同的 CSLA 对象（只读+可编辑+根+列表组合）及其存储过程之间，大约需要 1700 行，而 Linq2SQL + Repository 实现则需要 180 行。Linq2SQL 版本主要由生成的类组成，您的团队不需要阅读书籍即可理解这些类。是的，我使用 CodeSmith 生成了 CSLA 部分，但我现在相信具有单一责任位的 DRY 代码，并且 CSLA 实现现在在我看来就像昨天的英雄。

作为替代方案，我建议研究 Linq2Sql/Entity Framework/NHibernate 与 Repository 和 UnitOfWork 模式的结合。看一下 http://www.codeplex.com/backgroundmotion

干杯!

我们公司在一些项目中实施了 CSLA，而一些遗留项目仍然采用 CSLA。其他项目放弃了它，因为 CSLA 违反了简单明了的 OOP 规则：单一责任原则。

CSLA 对象是自我维持的，例如他们检索自己的数据，管理自己的行为，拯救自己。不幸的是，这意味着您的平均 CSLA 对象至少具有三个职责 - 表示域模型、包含业务规则以及包含数据访问定义（不是 DAL，或数据访问实现，如我之前所述/暗示的）时间。

我们广泛使用 CSLA。有几个好处；首先，我相信每个业务开发人员都应该阅读 Rocky Lhotka 的有关业务对象编程的书。我个人认为它是我有史以来最好的三本编程书籍之一。CSLA 是一个基于本书的框架，使用它可以让您的项目访问非常高级的功能，例如 n 级撤消、验证规则和可扩展性架构，同时为您提供详细信息。请注意，我说的是“提供”而不是“隐藏”。我发现 CSLA 最好的部分是让您了解所有这些内容是如何实现到源代码的，而不需要您自己重现它们。您可以根据需要选择使用任意数量的功能，但我发现，通过忠实于框架的设计模式，它确实可以让您摆脱麻烦。——拜伦

我们使用 CSLA 已有五年多了，我们认为它非常适合构建业务应用程序。与代码生成相结合，您可以在相对较短的时间内创建业务对象，并将精力集中在 肉 的应用程序。

我从 vb5 开始就一直在使用 CSLA，当时它更多的是模式的集合，而不是一个框架。随着 .NET 的引入，CSLA 变成了一个成熟的框架，但学习曲线却很艰巨。然而，CSLA 解决了所有业务开发人员在某个时候倾向于自己编写的许多内容（取决于项目范围）：验证逻辑、身份验证逻辑、撤消功能、脏逻辑等。所有这些东西都可以在一个很好的框架中免费获得。

正如其他人所说，作为一个框架，它迫使开发人员以类似的方式编写业务逻辑。它还迫使您为业务逻辑提供一定程度的抽象，这样不使用 MVC、MVP、MVVM 等 UI 框架就变得不那么重要了。

事实上，我认为，今天（在微软世界）这么多 UI 模式如此大肆宣传的原因是，人们长期以来一直在做一些令人难以置信的错误的事情（即，在 UI 中使用 DataGrid，洒水你的业务逻辑无处不在。蒂斯克蒂斯克）。从一开始就正确设计您的中间层（业务逻辑），您可以在任何 UI 中重用您的中间层。Win Form、ASP.NET/MVC、WCF 服务、WPF、Silverlight**、Windows 服务，...

但除此之外，对我来说巨大的回报是它内置的扩展能力。CSLA 使用可通过配置文件进行配置的代理模式。这允许您的业务对象在服务器之间进行远程调用，而无需编写一点代码。向您的系统添加更多用户？没问题，将您的 CSLA 业务对象部署到新的应用程序服务器，更改配置文件条目，然后 BAM！满足即时可扩展性需求。

将此与使用 DTO 进行比较，将业务逻辑存储在客户端（无论是什么客户端）上，并且必须将每个自己的 CRUD 方法编写为服务方法。哎呀！！！并不是说这是一个不好的方法，但我不想这样做。当有一个框架可以基本上为我做这件事时就不会了。

我将重申其他人在 CSLA 不是 ORM 中所说的话。CSLA 强制您向业务对象提供数据。他们不关心你从哪里获取数据。您可以使用 ORM 为业务对象提供数据。您还可以使用原始 ADO.NET、其他服务（RESTFUl、SOAP）、Excel 电子表格，我可以继续这里。

至于您对 TDD 的支持，我也从未尝试过在 CSLA 中使用这种方法。我采用的方法是使用类和序列图对中间层（业务对象）进行建模，最常见的是允许用例、屏幕和/或流程设计来指示。也许有点老派，但 UML 在我的设计和开发工作中始终为我提供了很好的帮助。我成功地设计和开发了非常大且可扩展的应用程序，至今仍在使用。在 WCF RIA 成熟之前，我将继续使用 CSLA。

** 有一些解决方法

我是 CSLA 的新手，但我了解这些概念，而且我已经知道它不是一个 ORM 工具，所以别再打败那些该死的鼓手了。CSLA 有一些功能我很喜欢，但使用它们感觉有点像幕后有一位魔术师。我想如果你不介意不知道它是如何工作的，那么你可以使用这些对象并且它们工作得很好。

对于初学者来说，学习曲线很大，我认为 5-15 分钟会受益匪浅。像 Microsoft 那样的用于学习基础知识的视频。或者发布一本包含代码的姊妹书怎么样，而不是发布代码并花几个月的时间来发布这本书？只是说 Lohtka 先生...我们在这本书出版之前就开始构建我们的东西，而我一直在挣扎。但就像我说的，我对此很陌生。

我们使用了 CSLA。我们让我们的对象适合他们的模具，然后使用框架提供的 10%。对象级撤消？没用过。NT层灵活性？没用过。我们最终编写了足够的业务规则代码，我认为我们从 CSLA 中获得的唯一好处就是复杂性。一些了解该框架的“老顽固”开发人员将其用作锤子，因为他们有一颗需要敲击的钉子。CSLA 就在他们的手中，我猜该框架的许多支持者也从这个角度看待事物。

我想我们经验丰富的开发人员很高兴，因为这对他们来说都是有意义的。我想，如果您的组织没有新手程序员，并且你们对编写具有良好格式模式的高效且简单的 POCO 对象感到厌倦，那么就去做吧。使用 CSLA。

我使用 CSLA 作为中型项目的业务对象框架。该框架自 VB6 时代以来已经走过了很长一段路，提供了非凡的灵活性和“开箱即用”的功能。CSLA 的移动智能对象使 UI 开发变得更加容易。然而，我同意其他人的观点，它并不是适合所有情况的正确工具。肯定会涉及一些开销，但也需要很大的功率。就我个人而言，我期待将 CSLA Light 与 Silverlight 结合使用。

优点：

  • 数据技术不可知论1
  • 安装基础庞大，而且免费！
  • 稳定且逻辑化的框架
  • 数据访问代码可以位于您的对象中或单独的程序集中
  • 属性和对象验证和授权

缺点

  • 代码需要维护很多2
  • 可能需要一个代码生成器才能有效使用
  • 学习曲线。CSLA 对象的结构很容易掌握，但其中的注意事项可能会让人头疼。


我不确定测试驱动设计。我不进行单元测试或测试驱动设计（对我来说很遗憾），所以我不知道单元测试是否与 TDD 不同，但我知道框架的最新版本附带了单元测试。


1 好事，因为数据访问技术永远不会长期保持不变。
2 该框架的最新版本使这一点变得更好。

很多人建议将代码生成与 CSLA 结合使用。我建议您查看我们支持的模板集，因为它们将极大地提高您的投资回报率。

谢谢-Blake Niemyjski（作者 CodeSmith CSLA 模板)

几年前我在一个项目中使用了它。但当项目完成后，我无法告诉任何人 CSLA 为我做了什么。当然，我继承了它的类。但我能够从几乎所有类中删除该继承，而无需进行重组。我们对 N 层的东西没有用处。n 级撤消速度太慢，我们无法使用它。所以我想最终它只会帮助我们模拟我们的课程。

话虽如此，其他团队已经开始使用它（在一个团队尝试创建自己的框架的可怕尝试之后）。所以里面一定有一些有价值的东西，因为他们都比我聪明！

我是一个 PHP 人。当我们开始使用 PHP 构建相对大型的应用程序时，我开始研究大量应用程序框架和 ORM，主要是在 PHP 领域，然后是 Java 和 .NET。我之所以关注 Java 和 .NET 框架，是为了不盲目使用任何 PHP 框架，而是首先尝试了解到底发生了什么，以及存在什么样的企业级架构。

因为我没有在现实世界的应用程序中使用过 CSLA，所以我无法评论它的优缺点，但我可以说的是，Lhotka 是软件架构领域中罕见的思想家（我并不是说只是专家）之一。虽然领域驱动设计这个名字是由 Eric Evans 创造的——顺便说一句，他的书也很棒，我谦虚地建议阅读它——Lhotka 多年来一直在应用领域驱动设计。话虽如此，无论您如何看待他的框架，都可以从他在该领域的深刻思想中受益。

您可以在 dotnetrocks.com/archives.aspx 上找到他的演讲，也可以在 dnrtv.com/archives.aspx 上找到他的视频（搜索 Lhotka）。

@Byron您喜欢的其他两本书是什么？

约翰，

我们有团队在 CSLA 2 到 3.5 中工作，并发现这是提供一致框架的好方法，因此所有开发人员都“以同样的方式做事”。很高兴大多数低价值代码都是生成的，我们知道当我们运行单元测试时，它们可以开箱即用地处理所有 CRUD 内容。我们发现我们的 TDD 确实伴随着我们设计时的重构而出现，并且 CSLA 并没有阻止我们做任何这些事情。

克里斯

我上次尝试使用 CSLA 是在 VB6 的石器时代。回想起来，如果我使用代码生成会更有效。如果您没有有效的代码生成工具以及将它们融入您的工作流程的策略，那么您应该避免使用 CSLA 这样的框架，否则您从 CSLA 获得的功能将无法弥补您花费在编写 n 行代码上的时间每个表的代码数，每列 n 行代码等。

我现在已经在几个项目中使用了 CSLA.NET，它在 Windows 窗体应用程序中最为成功，它具有丰富的数据绑定兼容性（asp.net 应用程序没有）。

它的主要问题是 TDD 支持，就像人们指出的那样，这是因为 Dataportal_XYZ 函数的黑盒行为，并且它无法允许我们模拟数据对象。已经努力解决这个问题 这 是最好的方法

我想使用它，但我当时的首席开发人员认为其中涉及太多“魔法”......

CSLA 是现有的最好的应用程序框架。洛基·霍特卡（Rocky LHotka）是一个非常聪明的人。他正在像 Martin Fowler、David S Platt 一样撰写软件开发史，但我最喜欢的作家是 Rod Stephens、Mathew McDonalds、Jeff Levinson、thearon willis 和 Louis Davidson（别名 sql 博士）。:-)专利：应用所有设计模式。缺点：学习困难，样本很少。

许可以下： CC-BY-SA 和 归因
不隶属于 StackOverflow
scroll top