logo标签列表

有人在现实世界中使用过CSLA吗？

.netframeworkscsla
51

我的公司主要的网络应用程序急需一套巧妙的库来使其更易于维护和扩展，我的一个同事建议使用CSLA。于是我买了这本书，但由于：

程序员不再阅读书籍

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

所以这里有我的问题：

  1. 有多少人在使用CSLA？
  2. 有哪些优缺点？
  3. CSLA是否真的不适用于TDD？
  4. 其他替代方案是什么？
  5. 如果您已经停止使用或决定不使用它，原因是什么？
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、Entity Framework等）的引入，也出现了许多有趣的模式。Fowler的书PoEAA详细介绍了许多适用于您的应用程序的模式。请注意，有些模式是竞争性的（即Active Record和Repository），因此只适用于特定的情况。虽然CSLA并不完全符合该书中描述的任何模式，但它最接近Active Record（尽管我认为声称这种模式完全匹配是短视的）。

5. 如果您停止使用它或反对它，原因是什么？
由于我认为应用程序的范围太大，超出了CSLA提供的好处，所以我没有完全推荐CSLA用于我的上一个项目。
我不会在Web项目中使用CSLA。我认为有其他更适合在那种环境下构建应用程序的技术。

总之，尽管CSLA绝非万能药，但它适用于某些情况。

希望这可以帮到您！

38
完全不同意 "很容易让新开发人员上手" 这种说法 - 依据我的经验，人们一开始会觉得非常复杂，而且这些复杂性并不会立即显现出它们给你带来了什么。 - Dan
4
非常好的回答。非常客观。 - Seth Spearman
4
"单元测试难度大" - 为什么会这样？"关注点分离不足（一般来说，业务对象内有数据访问代码）" - 没有阻止您使用存储库模式。"由于CSLA推广行为规范化而非数据规范化，因此可能出现名称相似但用途不同的业务对象。" - 正确，但目标是避免类之间的紧密耦合。 - J.C.
不容易，如果小组中没有人理解它，但是一旦有一个人知道DataPortal调用的魔法原因，那就很容易了。 - Tony Trembath-Drake
我已经对它进行了单元测试，包括核心CSLA和UI视图（WPF），没有太多麻烦。也许设置一个模拟数据库有点棘手，但任何真正有实质性的TDD都需要时间。 - Tony Trembath-Drake
23
阅读所有答案后，我注意到许多人对CSLA有一些误解。
首先，CSLA不是ORM。为什么我可以这么确定？因为Rockford Lhotka在.NET Rocks和Hanselminutes播客上的访谈中已经多次表明了这一点。找到任何Rocky接受采访的剪辑，他都会毫不含糊地陈述这一点。我认为这是人们理解CSLA的最关键的事实，因为几乎所有关于CSLA的误解都源于相信它是ORM或试图将其用作ORM。
正如Brad Leach在他的回答中所暗示的那样，CSLA对象模拟行为，尽管更准确地说，它们模拟数据的行为，因为数据对它们来说是不可分割的。CSLA不是ORM，因为它完全不关心您如何与数据存储交互。您应该使用某种数据访问层与CSLA一起使用，甚至可能是ORM。（我现在使用Entity Framework，它的效果非常好。）
现在，进入单元测试。我从未遇到过任何难以对我的CSLA对象进行单元测试的困难，因为我不会直接将数据访问代码放入我的业务对象中。相反，我使用某种存储库模式的变体。存储库由CSLA使用，而不是反过来。通过在我的单元测试中替换虚拟存储库并使用本地数据门户，一切都变得简单。（一旦Entity Framework允许使用POCO，这将变得更加简洁。）
所有这些都来自于意识到CSLA不是ORM。它可能会使用ORM，但它本身不是ORM。

干杯。

更新

我想再多说几句。

有些人说，与LINQ to SQL等技术相比，CSLA过于冗长。但是这是在比较苹果和橙子。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配合得很好，所以这不是问题。

2
你准确地指出了许多误解！说得好！ - J.C.
1
呵呵，你恰好也击中了我一个 ORM 问题的要害，这并非巧合。 - J.C.
我已经从 MS 世界转向了 Mac/Unix 世界，但在离开之前，我发现使用 CSLA 和 Dapper 作为 ORM 带来了很多乐趣。像 EF 这样的丰富 ORM 能够很好地工作，但对于 CSLA 来说有点过度设计了。 - Gregory Higley
19

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

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

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

关键是要记住使用CSLA来建模用户与某个应用程序上的表单的交互方式。对我来说最有效的方法是设计UI并了解其流程、行为和验证规则，然后再构建CSLA对象。不要让您的CSLA对象驱动UI设计。

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

我们还内置了机制，以异步方式执行针对Web服务的验证（即检查柜台方的信用限额范围是否符合主控方的要求）。

CSLA 在 UI、业务逻辑和持久化之间实行了强分离，并针对它们编写了大量单元测试。尽管您是从 UI 设计中进行驱动，这可能并不严格符合 TDD，但这并不意味着它无法进行测试。

唯一真正的替代方案是创建自己的模型\业务对象，但很快您就会发现自己需要实现 CSLA 已经提供的功能（INotifyPropertyChanged、IDataErrorInfo、PushState、PopState 等）。

13

我曾经在一个项目中使用过CSLA，它非常出色，让事情变得更加简单和整洁。

我们不再需要让团队按照各自的风格编写业务对象，现在有一个共同的标准来进行工作。

//andy

1
我也认为这是它最大的优点。它强制实施团队中的标准设计和思维方式。 - DancesWithBamboo
11

我几年前曾经接触过它。它是一个非常出色的架构，但同时也非常复杂，很难理解或修改，并且它解决的问题大多数开发基于Web的应用程序并没有必要解决。它更多是为Windows应用程序和处理多级撤销而开发的，强调事务逻辑。你可能会听到人们说，因为Web应用程序是请求-响应方式，所以使用这个架构不太合适，但对于使用AJAX风格的Web应用程序，这个论点可能就不成立了。

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

综合考虑，它不是我首选的架构。

2
+1. 我加入了一个非常庞大的Win Forms CSLA项目的团队，但是我进来的时候已经是几个版本后了。这个项目非常复杂。只有当“它解决的问题”明显优于其他一切时，你才应该选择CSLA。我提醒你了。在我看来，缺乏单元测试功能使得CSLA不适用于关键系统。我们只有大约4％的测试覆盖率。CSLA对依赖注入毫无反应，你的自定义代码必然与框架紧密耦合，涉及所有继承和覆盖。 - radarbob
8

虽然我同意许多评论，尤其是单元测试方面的评论，但我要为CSLA辩护...

我的公司广泛使用它来创建Windows Forms数据输入应用程序，并获得了很高的成功度。

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

总的来说，我认为它可能引起的任何问题都被其带来的好处所超越。

更新：除此之外，我们仍在为我们的Windows Forms应用程序使用它，但试验表明，如果您不需要太多它的功能，当您创建Web站点等其他应用程序时，它可能过于繁琐，因此我们现在正在研究更轻量级的选择。

我们正在做类似的事情，我很想听听您看过的一些轻量级选项。 - Span
@Span - 我们正在使用 NHibernate。 - Simon Keep
7

我加入了一个团队，他们强制使用CSLA。我们不使用远程数据门户，这也是我能接受使用该框架的唯一原因。我从未认同CSLA的理念，也许这就是为什么我对它没有好感的原因，抱歉。

以下是其中的一些问题：

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

我们有这些只读列表和非只读列表，这完全荒谬。如果我必须向列表添加项目，则必须重新创建整个列表……你是认真的吗？

然后csla想要管理我的对象状态，这很好，但实际上没有什么东西被暴露出来。有时我想手动更改对象状态，而不是再次获取它，这似乎是csla希望我做的事情。我最终会创建许多属性来公开csla认为我不应直接访问的选项。

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

检查框架源代码，我认为其中的反射代码太重了。

使用csla的原因：

  • 直接使用.NET框架对你来说过于强大。
  • 你的开发人员经验不足，无法掌握模式的概念，那么csla将几乎让每个人都在同一页面上。
    1. 我不需要在我的代码和.NET框架之间设置路障……我被这些列表对象困住了。
6
不要将CSLA从列表中删除，但在使用它之前，请研究其好处并确保它们确实适用。您的团队能否正确/一致地实现它？需要远程和门户舞蹈吗？
我认为除了所有理论思考之外，重要的是遵循基本的经过验证的模式编写干净/可维护/可扩展/可测试的代码。
我计算了一个项目特定领域所需的代码行数，从CSLA转换而来。在所有不同的CSLA对象（只读+可编辑+根+列表组合）及其存储过程之间，大约需要1700行，而Linq2SQL + Repository实现则需要180行。 Linq2SQL版本主要由生成的类组成，您的团队不需要消耗大量时间去理解。是的，我使用CodeSmith生成CSLA部分，但我现在相信DRY代码具有单一责任位，并且CSLA实现现在看起来像昨天的英雄。
作为替代方案，我想建议查看与Repository和UnitOfWork模式相结合的Linq2Sql/Entity Framework/NHibernate。请查看http://www.codeplex.com/backgroundmotion 干杯！
6

我们开始使用CSLA是因为我们认为它可以帮助我们的模型层。但事实上，它有点过头了，现在我们主要只使用SmartDate类，因为我们已经链接到了这个库。

我们认为验证接口会真正帮助我们执行业务规则，但它与WCF和序列化不兼容（我们仍然停留在2.0.3.0版本，所以可能已经有所改变）。

6
我们公司在一些项目中实践了CSLA，但有一些遗留项目仍然采用CSLA。其他项目则放弃了CSLA，因为它违反了一个简单明了的面向对象编程规则：单一职责原则。
CSLA对象是自我维护的，例如，它们检索自己的数据，管理自己的行为，保存自己的数据。不幸的是，这意味着您平均的CSLA对象至少具有三个职责--表示领域模型、包含业务规则和包含数据访问定义（而不是DAL或数据访问实现，正如我之前所述/暗示的）同时存在。
3
CSLA将自身的检索和持久化逻辑封装在对象内部，但并不定义其如何实现。您可以轻松地拥有一个由CSLA对象调用的DAL。 DataPortal_XYZ方法的目的是在层间传输对象。据我所知，封装是面向对象编程中非常重要的概念。 - Darren Kopp
1
虽然你说得有道理，但我认为对象内部具有检索和持久化行为是SRP（如果不是OO）本身的违规行为。不幸的是，这个争论更多的是宗教性质的，所以我愿意同意我们的分歧。 - Jon Limjap
网页内容由stack overflow 提供, 点击上面的
可以查看英文原文，
原文链接