51

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

程序员不再读书

我想评估一下 SOFlow 社区对它的看法。

所以这是我的问题：

  1. 人们如何使用 CSLA？
  2. 优缺点都有什么？
  3. CSLA 真的不适合 TDD 吗？
  4. 我的替代方案是什么？
  5. 如果您已停止使用它或决定反对，为什么？
4

23 回答 23

72

在我具体回答你的问题之前，我想先谈谈一些想法。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、实体框架等）开始，还发展出许多有趣的模式。Fowlers 的书PoEAA详细介绍了许多可能适合您的应用的模式。请注意，某些模式是相互竞争的（即 Active Record 和 Repository），因此旨在用于特定场景。虽然 CSLA 与该书中描述的任何模式都不完全匹配，但它与 Active Record 最相似（尽管我认为声称与该模式完全匹配是短视的）。

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

总之，虽然 CSLA 绝不是灵丹妙药，但它适用于某些场景。

希望这可以帮助！

于 2008-08-18T22:32:10.427 回答
23

在阅读了所有的答案后，我注意到相当多的人对 CSLA 有一些误解。

首先，CSLA 不是 ORM。我怎么可以这么肯定地说？因为 Rockford Lhotka 在.NET Rocks和Hanselminutes播客的采访中多次表示过这一点。寻找洛基接受采访的任何一集，他会毫不含糊地陈述它。我认为这是人们理解的最关键的事实，因为几乎所有关于 CSLA 的误解都源于相信它是 ORM 或试图将其用作 ORM。

正如 Brad Leach 在他的回答中提到的那样，CSLA 对象为行为建模，尽管说它们为数据的行为建模可能更准确，因为数据是它们不可或缺的一部分。CSLA 不是 ORM，因为它完全不知道您如何与数据存储通信。您应该在 CSLA 中使用某种数据访问层，甚至可能是 ORM。（我愿意。我现在使用 Entity Framework，效果很好。）

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

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

干杯。

更新

我想我会再发表一些评论。

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

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

于 2009-08-02T17:40:53.333 回答
19

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

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

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

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

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

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

CSLA 在您的 UI、BusinessLogic 和 Persistance 之间实施了严格的分离，我们针对它们编写了大量的单元测试。它可能不是严格的 TDD，因为您是从 UI 设计驱动它的，这并不意味着它不可测试。

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

于 2008-08-18T22:50:26.600 回答
13

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

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

//安迪

于 2008-10-30T11:35:45.113 回答
11

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

它有一个非常深的对象模型，可能需要一段时间才能真正将你的大脑包裹在它周围。当然，很多东西可以在几年内改变。我很想听听其他最近的意见。

综合考虑，它不会是我的首选建筑。

于 2008-08-18T21:48:44.680 回答
8

为 CSLA 辩护，尽管我确实同意许多评论，尤其是单元测试的评论...

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

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

总的来说，我会说它引起的任何问题都不仅仅是好处。

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

于 2008-08-28T14:42:25.067 回答
7

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

几个问题：

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

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

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

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

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

使用 csla 的原因：

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

  • 您的开发人员经验不足，无法掌握模式的概念，那么 csla 几乎会让每个人都在同一页面上。

    1. 我不需要在我的代码和 .NET 框架之间设置障碍……我被这些列表对象困住了。
于 2011-02-22T00:30:44.770 回答
6

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

我们认为验证接口确实可以帮助我们执行业务规则，但它不适用于 WCF 和序列化（我们仍然停留在版本 2.0.3.0，所以事情可能已经改变）。

于 2008-08-18T21:34:26.893 回答
6

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

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

于 2008-08-18T23:10:51.410 回答
6

不要将 CSLA 列入清单，但在使用它之前，请研究其好处并确保它们确实适用。您的团队是否能够正确/一致地实施它？需要远程处理和门户舞蹈吗？

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

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

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

干杯!

于 2009-04-06T07:01:39.913 回答
5

我们广泛使用 CSLA。有几个好处；首先，我相信每一位业务开发人员都应该阅读 Rocky Lhotka 的关于业务对象编程的书。我个人发现它是我有史以来最好的 3 本书。CSLA 是基于本书的框架，使用它可以让您的项目访问非常高级的功能，例如 n 级撤消、验证规则和可伸缩性架构，同时为您提供详细信息。注意我说的是“提供”而不是“隐藏”。我发现 CSLA 最好的部分是让您了解所有这些东西是如何实现到源代码的，而无需您自己复制它们。您可以根据需要选择使用尽可能多或少的功能，但我发现通过忠实于框架的设计模式，它真的让你远离麻烦。——拜伦

于 2009-01-28T13:33:45.093 回答
4

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

于 2008-09-23T14:22:51.360 回答
4

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

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

事实上，我认为今天（在微软世界）如此大肆宣传这些 UI 模式的原因是人们长期以来一直在做一些令人难以置信的错误（即，在你的 UI 中使用 DataGrids，洒你的业务逻辑无处不在。tisk tisk）。从一开始就正确设计中间层（业务逻辑），您可以在任何 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 一起使用。我采用了使用类和序列图对中间层（ala 业务对象）建模的方法，通常允许用例、屏幕和/或流程设计来决定。也许有点老派，但 UML 在我的设计和开发工作中一直为我提供了很好的服务。我已经成功地设计和开发了今天仍在使用的非常大且可扩展的应用程序。在 WCF RIA 成熟之前，我将继续使用 CSLA。

** 有一些解决方法

于 2010-03-05T06:09:21.260 回答
4

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

初学者有一个很大的学习曲线，我认为有 5-15 分钟会受益匪浅。像微软这样的视频来学习基础知识。或者，如何发布带有代码的配套书籍，而不是发布代码并花费数月时间才能将这本书出版？只是说 Lohtka 先生......我们在这本书之前就开始构建我们的东西，我一直在挣扎。但就像我说的，我是新手。

我们使用了 CSLA。我们让我们的对象适合他们的模具，然后使用框架提供的 10%。对象级撤消？没用过。NTier 灵活性？没用过。我们最终编写了足够多的业务规则代码，我认为我们从 CSLA 中得到的唯一东西就是复杂性。一些知道该框架的“长期”开发人员将其用作锤子，因为他们有一个需要敲击的钉子。CSLA 在他们的腰带上，我猜很多框架的支持者也从这个角度看待事情。

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

于 2010-12-13T23:00:40.607 回答
3

我使用 CSLA 作为中型项目的业务对象框架。该框架与 VB6 时代相比已经取得了长足的进步，并提供了非凡的灵活性和“开箱即用”的功能。CSLA 的移动智能对象使 UI 开发变得更加容易。但是，我同意其他人的观点，它并不是适用于所有情况的正确工具。肯定会涉及一些开销，但也有很多权力。就个人而言，我期待将 CSLA Light 与 Silverlight 一起使用。

优点：

  • 数据技术无关1
  • 大型安装基础，它是免费的！
  • 稳定的逻辑框架
  • 数据访问代码可以在您的对象中或在单独的程序集中
  • 属性和对象验证和授权

缺点

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


我不确定测试驱动设计。我不进行单元测试或测试驱动设计（我感到羞耻），所以我不知道单元测试是否与 TDD 不同，但我知道最新版本的框架带有单元测试。


1好事，因为数据访问技术永远不会长期保持不变。
2这在最近版本的框架中变得更好了。

于 2009-06-08T04:54:53.320 回答
3

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

谢谢 -Blake Niemyjski（CodeSmith CSLA 模板的作者）

于 2010-08-05T16:11:14.600 回答
2

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

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

于 2008-09-23T14:16:36.010 回答
2

我是一个 PHP 人。当我们开始使用 PHP 构建相对大规模的应用程序时，我开始研究大量的应用程序框架和 ORM，主要是 PHP 世界，然后是 Java 和 .NET。我还研究 Java 和 .NET 框架的原因是不要盲目地使用任何 PHP 框架，而是首先尝试了解真正发生了什么，以及存在什么样的企业级架构。

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

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

@Byron 你喜欢的另外两本书是什么？

于 2009-02-10T04:12:42.563 回答
2

约翰，

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

克里斯

于 2009-05-06T14:05:59.553 回答
2

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

于 2009-05-08T10:51:59.987 回答
2

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

它的主要问题是人们一直指出的 TDD 支持，这是因为 Dataportal_XYZ 函数的类似黑盒的行为，它无法让我们模拟数据对象。已经努力解决这个问题，这是最好的方法

于 2009-09-17T12:44:03.153 回答
1

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

于 2008-09-23T14:19:23.710 回答
0

CSLA 是现有的最佳应用程序框架。Rocky LHotka 是一个非常但非常聪明的人。他正在像 Martin Fowler、David S Platt 一样撰写软件开发的历史，但我最喜欢的作家是 Rod Stephens、Mathew mcDonalds、Jeff Levinson thearon willis 和 Louis Davidson 别名 sql 博士。:-) 优点：应用了所有设计模式。缺点：难学，样本少。

于 2010-03-02T06:51:27.920 回答