我公司的主要Web应用程序渴望一组漂亮的库，以使其在某种程度上可维护和可扩展，并且我的一位同事建议CSLA。所以我买了那本书，但是：

programmers don't read books anymore

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

所以这是我的问题：

• 人们可能如何使用CSLA？
• 优缺点都有什么？
• CSLA真的不适合TDD吗？
• 我有什么选择？
• 如果我们已停止使用它或者决定为什么使用它？

解决方案

回答

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

我们认为验证接口确实可以帮助我们强制执行业务规则，但是它不能与WCF和序列化一起很好地工作(我们仍然停留在2.0.3.0版本上，所以情况可能有所改变)。

回答

我几年前有经验。它是一个出色的体系结构，但非常复杂，难以理解或者更改，它解决了我们大多数开发基于Web的应用程序不一定具有的问题。它是为基于Windows的应用程序和处理多级撤消而开发的，重点是事务逻辑。我们可能会听到人们说，由于Web应用程序是页面级的请求-响应，因此这是不合适的，但是对于AJAX风格的Web应用程序，此参数可能没有太多用处。

它具有非常深入的对象模型，可能需要一段时间才能真正将大脑包起来。当然，几年后可能会发生很多变化。我想听听其他最近的意见。

考虑到所有因素，这不是我选择建筑的第一选择。

回答

在我具体回答问题之前，我想说几句话。 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到SQL，实体框架等)的引入，也开发出许多有趣的模式。 Fowlers预订PoEAA，详细介绍了许多可能适合应用程序的模式。请注意，某些模式是相互竞争的(即Active Record和Repository)，因此应将其用于特定方案。尽管CSLA与该书中描述的任何模式都不完全匹配，但它与Active Record最相似(尽管我认为声称完全匹配此模式是短视的)。

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

总而言之，尽管CSLA只是灵丹妙药，但它适用于某些情况。

希望这可以帮助！

回答

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

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

缺点是它有点学习曲线。

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

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

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

CSLA在UI，BusinessLogic和Persistance之间实现了强烈的分隔，我们针对它们编写了许多单元测试。严格来说，它不是TDD，因为我们是从UI设计中驱动它的，这并不意味着它就不可测试。

唯一真正的选择是创建自己的模型\业务对象，但是很快我们就实现了CSLA开箱即用的功能(INotifyPropertyChanged，IDataErrorInfo，PushState，PopState等)。

回答

我们公司在其某些项目中实践CSLA，而一些遗留项目仍然是CSLA。由于CSLA违反了一个简单而简单的OOP规则：单一责任原则，因此其他项目放弃了它。

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

回答

为了捍卫CSLA，尽管我确实同意许多意见，尤其是对单元测试的意见。

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

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

总体而言，我要说的是，由此带来的任何问题都远远超出了收益。

更新：此外，我们仍在Windows窗体应用程序中使用它，但将其用于其他应用程序(例如网站)的实验表明，当我们不需要太多功能时，它可能会很麻烦，我们现在正在调查这些方案的重量更轻。

回答

几年前，我将其用于一个项目。但是当项目完成后，我无法告诉任何人CSLA为我做了什么。当然，我从它的类继承而来。但是我几乎无需重组就可以从几乎所有类中删除该继承。我们没有用到N层的东西。 n级撤消是如此之慢，以至于我们无法使用它。因此，我想最后它只能帮助我们为课程建模。

话虽如此，但其他团队已经开始使用它(在一个团队经过艰苦尝试创建自己的框架之后)。所以那里一定有值得的东西，因为它们都比我聪明！

回答

我想使用它，但是我当时的首席开发人员想到了太多"魔术"的想法……

回答

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

回答

我已经使用CSLA进行了一个项目，它工作得很好，并使事情变得更加简单和整洁。

我们知道我们有一个共同的标准可以与团队以自己不同的个人风格来编写业务对象。

// andy

回答

我们广泛使用CSLA。有几个好处；首先，我相信每一个业务开发人员都应该阅读Rocky Lhotka关于Business Objects编程的书。我个人发现它在我的前三本最佳编程书籍中。 CSLA是基于本书的框架，使用它可以使项目访问非常高级的功能，例如n级撤消，验证规则和可伸缩性体系结构，同时为我们提供详细信息。注意，我说的是"提供"而不是"隐藏"。我发现CSLA最好的部分是让我们了解如何将所有这些事情实现到源代码，而无需我们自己复制它们。我们可以选择使用所需的功能，但我发现通过忠于框架的设计模式，确实可以避免麻烦。
-拜伦

回答

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

因为我没有在实际的应用程序中使用CSLA，所以无法评论它的优缺点，但是我能说的是Lhotka是很少见的思想家-我并不是在说软件架构领域的专家。尽管域名驱动设计这个名字是由埃里克·埃文斯(Eric Evans)创造的-顺便说一句，他的书也很棒，我谨建议阅读。话虽如此，无论我们如何看待他的框架，都将从他在该领域的深刻思想中受益。

我们可以在dotnetrocks.com/archives.aspx和dnrtv.com/archives.aspx的视频中找到他的演讲(搜索Lhotka)。

拜伦
我们还喜欢其他两本书吗？

回答

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

我认为，除了理论上的所有思考之外，它还涉及遵循基本可靠模式的干净/可维护/可扩展/可测试的代码。

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

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

干杯!

回答

约翰，

我们的团队从2到3.5在CSLA中工作，并且发现这是提供一致框架的好方法，因此所有开发人员都"以相同的方式进行操作"。很棒的是，大多数低价值代码都生成了，我们知道在运行单元测试时，它们对于所有CRUD东西都是开箱即用的。我们发现，TDD确实是我们进行设计时要进行的重构，CSLA并没有阻止我们进行任何此类重构。

克里斯

回答

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

回答

我正在使用CSLA作为中型项目的业务对象框架。从VB6时代开始，该框架已经走了很长一段路，并提供了极大的灵活性和"开箱即用"的功能。 CSLA的移动智能对象使UI开发更加容易。但是，我同意其他人的观点，这并不是适用于每种情况的正确工具。肯定会涉及一些开销，但也会带来很多功能。我个人很期待将CSLA Light与Silverlight一起使用。

优点：

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

缺点

• 该代码可以维护很多

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

我不确定测试驱动的设计。我没有单元测试或者测试驱动的设计(可耻的是我)，所以我不知道单元测试是否不同于TDD，但是我知道框架的最新版本是单元测试附带的。

1好事，因为数据访问技术永远不会长久保持不变。
2在最新版本的框架中，情况已变得更好。

回答

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

首先，CSLA不是ORM。我怎么能这么肯定地说呢？因为Rockford Lhotka曾在.NET Rocks和Hanselminutes播客的采访中多次声明自己。寻找落基接受采访的任何情节，他会以不确定的方式陈述这一情节。我认为这是人们要理解的最关键的事实，因为几乎所有对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层持久性对我来说是最重要的。如果我想通过网络使用Entity Framework或者LINQ to SQL，则必须在两者之间放置WCF之类的东西，这极大地增加了工作量和复杂性，以至于我认为它比CSLA更为冗长。 (现在，我是WCF，REST和SOA的粉丝，但是可以在我们真正需要它的地方使用它，例如，当我们要将服务公开给第三方时。对于大多数业务应用程序，它不是实际上，在最新版本的CSLA中，Rocky提供了我使用的" WCFDataPortal"。效果很好。

我忠实于SOLID，TDD和其他现代软件开发原则，并在可行的地方使用它们。但是我认为CSLA的好处超过了那些正统的反对意见，无论如何，我都设法使CSLA与TDD很好地(且容易地)一起工作，所以这不是问题。

回答

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

就像人们一直指出的那样，主要问题是TDD支持，这是因为Dataportal_XYZ函数的行为像黑盒一样，并且无法让我们模拟数据对象。已经尝试解决此问题，这是最好的方法

回答

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

回答

自vb5以来，我一直在使用CSLA，当时它更多是模式的集合，而不是框架。随着.NET的引入，CSLA变成了功能完善的框架，并且学习曲线也很大。但是，CSLA解决了所有业务开发人员往往会在某个时候(取决于项目范围)自行编写的许多事情：验证逻辑，身份验证逻辑，撤消功能，脏逻辑等。框在一个​​不错的框架中。

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

实际上，我会争辩说，今天(在Microsoft世界中)如此众多的UI模式被如此大肆宣传的原因是，人们做错事已经很长时间了(例如，在UI中使用DataGrid，业​​务逻辑无处不在。从一开始就正确设计中间层(业务逻辑)，我们可以在ANY 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。

**有一些解决方法

回答

许多人建议将代码生成与CSLA一起使用。我建议我们检查一下我们支持的模板集，因为它们将极大地提高投资回报率。

谢谢
-Blake Niemyjski(CodeSmith CSLA模板的作者)

回答

我是CSLA的新手，但我了解这些概念，并且我已经了解它不是ORM工具，因此请击败那些该死的鼓手。我喜欢CSLA的功能，但使用它们的感觉有点像幕后有魔术师。我猜如果我们不介意不知道它是如何工作的，那么我们可以使用这些对象并且它们可以正常工作。

对于初学者来说，学习曲线很大，我认为有5至15分钟的学习时间会大大受益。像Microsoft这样的视频可用于学习基础知识。还是发布带有代码的配套书，而不是发布代码并花数月的时间来发布该书呢？只是对Lohtka先生说...我们在本书开始之前就开始制作自己的东西，而我一直都在挣扎。但是就像我说的那样，我是新手。

我们使用CSLA。我们使对象适合其模具，然后使用框架提供的内容的10％。对象级撤消？没有使用它。 NTier的灵活性？没有使用它。我们最终编写了足够的业务规则代码，以至于我认为摆脱CSLA的唯一困难就是复杂性。一些知道该框架的"长牙"开发人员将其用作锤子，因为他们有一个需要打的钉子。 CSLA处于领导地位，我猜想该框架的许多支持者也从这个角度来看事情。

我想我们经验丰富的开发人员很高兴，因为这对他们来说很有意义。我想如果组织没有新手程序员，而我们又因为编写格式正确的高效简单的POCO对象而感到无聊，那就去做吧。使用CSLA。