有没有人有CSLA的实际经验？

Question

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

  

程序员不再读书了

我想衡量一下SOFlow社区对它的看法。

所以这是我的问题：

1. 人们如何使用CSLA？
2. 有什么优点和缺点？
3. CSLA真的不适合TDD吗？
4. 我有什么选择？
5. 如果你已经停止使用它或决定反对原因？

Answer 1

在我专门回答你的问题之前，我想提出一些想法。 CSLA是否适合您的项目？这取决于。我个人认为CSLA适用于基于桌面的应用程序，它不会将单元测试视为高优先级。如果您想轻松扩展到n层应用程序，CSLA非常棒。 CSLA往往会出现一些问题，因为它不允许纯单元测试。这是真的，不过像技术上的任何东西一样，我相信 No One True Way 。单元测试可能不是您为特定项目进行的。对一个团队和一个项目有效的方法可能不适用于其他团队或其他项目。

对于CSLA也存在许多误解。它不是ORM。它不是NHibernate的竞争对手（实际上使用CLSA Business Objects＆amp; NHibernate作为数据访问非常合适）。它规范了移动对象的概念。

<强> 1。有多少人在使用CSLA？
基于CSLA Forums，我想说有很多基于CSLA的项目。老实说，我不知道有多少人实际使用它。我过去曾在两个项目中使用它。

<强> 2。有什么优点和缺点？
虽然很难在一个简短的清单中总结，但这里有一些可以想到的优点 优点：

• 让新开发者很容易 加速。 CSLA书和样本 应用程序是很好的资源，以加快速度。
• 验证框架是真正的世界级 - 并且已被许多其他非CSLA项目和技术“借用”。
• 业务对象中的n级撤消
• 配置n-line可扩展性的行更改（注意：甚至不是 重新编译是必要的）
• 关键技术是从“真实”代码中抽象出来的。当WCF是 介绍，它对它的影响很小 CSLA代码。
  
• 可以在Windows和Web项目之间共享您的业务对象。
• CSLA促进行为的规范化，而不是数据的规范化（让数据库保持数据规范化）。

缺点：

• 单元测试难度
• 缺乏关注点分离（通常您的业务对象中包含数据访问代码）。
• 由于CSLA促进行为的规范化，而不是数据的规范化，这可能导致业务对象的命名方式相似，但目的不同。这可能会导致一些混乱，并且感觉您没有适当地重复使用对象。也就是说，一旦实现了生理上的飞跃，它就更有意义了 - 以“旧”的方式构建物体似乎是不合适的。
• 以这种方式构建应用程序不是“时尚”。您可能很难找到对该技术充满热情的开发人员。

第3。看完后，CSLA真的不适合TDD吗？
我还没有找到一种与CSLA进行TDD的有效方法。也就是说，我相信有很多比我更聪明的人可能已经尝试过这一点并取得了更大的成功。

<强> 4。我有什么选择？
Domain-Driven-Design目前正在大力推动（理所当然 - 对某些应用程序而言非常棒）。从LINQ（以及LINQ到SQL，实体框架等）的引入中也发展了许多有趣的模式。 Fowlers预订PoEAA，详细介绍了许多适合您应用的模式。注意，一些模式是竞争的（即活动记录和存储库），因此意味着用于特定场景。虽然CSLA与该书中描述的任何模式都不完全匹配，但它最接近于Active Record（尽管我认为声称与此模式完全匹配是短视的。）

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

总之，虽然CSLA不是银弹，但它适用于某些情况。

希望这有帮助！

Answer 2

在阅读完所有答案后，我注意到很多人对CSLA有一些误解。

首先， CSLA不是ORM 。我怎么能这么说呢？因为Rockford Lhotka在 .NET Rocks 和 Hanselminutes 播客的采访中多次表明了这一点。寻找任何插曲，其中Rocky接受采访，他会毫不含糊地说出来。我认为这是人们理解的最关键的事实，因为几乎所有关于CSLA的误解都源于相信它是一个ORM或者试图将它作为一个ORM使用。

正如Brad Leach在他的回答中提到的那样，CSLA反对模型行为，尽管说他们模拟数据行为可能更准确，因为数据是他们不可或缺的。 CSLA不是ORM，因为它与您与数据存储的对话完全不可知。你 应该使用CSLA的某种数据访问层，甚至可能是ORM。 （我这样做。我现在使用实体框架，它可以很好地工作。）

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

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

干杯。

更新

我以为我会发表更多评论。

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

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

Answer 3

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

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

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

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

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

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

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

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

Answer 4

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

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

考虑到所有因素，这不是我对建筑的首选。

Answer 5

我已经将CSLA用于一个项目，它工作得很好，使事情更简单，更整洁。

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

//安迪

Answer 6

为了保卫CSLA，虽然我同意许多评论，特别是单位测试一个......

我公司广泛用于Windows Forms数据录入应用程序，取得了很大的成功。

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

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

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

Answer 7

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

其中一些问题：

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

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

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

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

检查框架源代码，它看起来很反映我的反射代码。

使用csla的原因：

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

• 你的开发人员没有经验丰富，无法掌握模式的概念，因此csla几乎每个人都在同一页面上。

  1. 我的代码和.NET框架之间不需要路障......我对这些列表对象感到困惑。

Answer 8

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

我认为，除了所有的理论思考之外，它都是关于基本可靠模式的清洁/可维护/可扩展/可测试代码。

我计算了从CSLA转换的项目的特定域中所需的代码行数。在所有不同的CSLA对象（readonly + editable + root + list组合）和它们存储的proc之间它占用了大约1700行，而Linq2SQL + Repository实现需要180行。 Linq2SQL版本主要由生成的类组成，您的团队不需要使用本书来理解。是的，我使用CodeSmith来生成CSLA部分，但我现在相信具有单一责任位的DRY代码，而CSLA实现现在看起来像昨天的英雄。

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

干杯！

Answer 9

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

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

Answer 10

我们开始使用CSLA，因为我们认为这对我们的模型层有帮助。有点矫枉过正，我们现在使用的大部分都是SmartDate类，因为我们已经链接到了库。

我们认为验证界面确实可以帮助我们实施业务规则，但它在WCF和序列化方面效果不佳（我们仍然停留在版本2.0.3.0上，所以事情可能已经改变了。）

Answer 11

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

Answer 12

我们广泛使用CSLA。有几个好处;首先，我相信每一位业务开发人员都应该阅读Rocky Lhotka关于Business Objects编程的书。我个人发现它是我有史以来最好的3本最佳编程书籍。 CSLA是一个基于本书的框架，使用它可以让您的项目访问非常高级的功能，如n级撤销，验证规则和可扩展性架构，同时为您提供详细信息。注意我说“提供”而不是“隐藏”。我发现CSLA最好的部分是让你了解所有这些东西是如何在源代码中实现的，而不是让你自己重现它们。您可以根据需要选择使用尽可能多的功能，但我发现通过坚持框架的设计模式，它确实可以帮助您摆脱困境。 --Byron

Answer 13

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

初学者有一个很大的学习曲线，我认为5-15分钟会有很大的好处。像微软这样的视频有助于学习基础知识。或者如何使用代码发布伴侣书而不是发布代码并花费数月才能获得该书？只是说Lohtka先生......我们开始在本书之前构建我们的东西，而且我一直在努力。但就像我说的那样，我是新手。

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

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

Answer 14

我使用CSLA作为中型项目的业务对象框架。该框架与VB6时代相距甚远，并提供了非凡的灵活性和“开箱即用”功能。 CSLA的移动智能对象使UI开发变得更加容易。但是，我同意其他人的意见，它不适合所有情况。肯定会有一些开销，但也有很多权力。就个人而言，我期待着使用CSLA Light和Silverlight。

优点：

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

缺点

• 代码可以维护很多 ²
• 可能需要代码生成器才能有效使用
• 学习曲线。 CSLA对象的结构很容易掌握，但警告可能会引起头痛。

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

< / p>

¹ 好事，因为数据访问技术永远不会保持不变 ² 最近版本的框架已经变得更好了。

Answer 15

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

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

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

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

将此与使用DTO进行比较，将业务逻辑存储在客户端（无论客户端是什么），并且必须将每个自己的CRUD方法编写为服务方法。 YIKES！不是说这是一个糟糕的方法，但我不想这样做。不是当有一个框架在那里基本上为我做。

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

至于你对TDD的支持，我从来没有尝试过将这种方法用于CSLA。我采用的方法是使用类和序列图来模拟我的中间层（ala业务对象），最常见的是允许用例，屏幕和/或流程设计来指示。也许有点老派，但UML在我的设计和开发工作中一直很好。我已成功设计和开发了目前仍在使用的非常大且可扩展的应用程序。在WCF RIA成熟之前，我将继续使用CSLA ..

**有一些解决方法

Answer 16

很多人建议在CSLA中使用Code Generation。我建议您查看我们支持的模板集，因为它们会极大地提高您的投资回报率。

由于 -Blake Niemyjski（CodeSmith CSLA Templates的作者）

Answer 17

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

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

Answer 18

我是一个PHP家伙。当我们开始使用PHP构建相对大规模的应用程序时，我开始研究许多应用程序框架和ORM，主要是在PHP世界中，然后是Java和.NET。我之所以看到Java和.NET框架，也不是盲目地使用任何PHP框架，而是首先尝试了解实际情况，以及那种企业级架构。

因为我没有在现实世界的应用程序中使用CSLA，所以我不能评论其优缺点，但我能说的是Lhotka是一个罕见的思想家 - 我不是说只是专家 - 软件建筑领域。尽管“领域驱动设计”这个名字是由埃里克·埃文斯创造的 - 他的书也非常棒，我谦虚地建议阅读它--Lhotka多年来一直在应用域驱动设计。话虽如此，无论你如何看待他的框架，都可以从他在该领域的深刻见解中获益。

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

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

Answer 19

约翰，

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

克里斯

Answer 20

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

Answer 21

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

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

Answer 22

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

Answer 23

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