什么是CSLA框架及其用途？

Question

什么是CSLA框架及其用途？

csla

26

什么是CSLA框架及其用途？

- Greens

6个回答

12

CSLA是一个业务对象框架，可让您轻松创建基于数据层的业务对象。它允许您使用坚实的面向对象原则和良好的关注点分离来设计应用程序。

我强烈建议您阅读Rocky Lhotka撰写的Expert C# 2008 Business Objects中介绍的CSLA书籍。这不仅将教您有关该框架的知识，还将教您良好的软件架构原则。

您可以在Amazon上获取该书

- Jamie Wright

1

这得益于Rocky的支持，而且支持得非常好。有一个报告漏洞的地方，通常会很快得到回应。 - Jamie Wright

21

容易？我可以引用你的话吗？ - D3vtr0n

1

可以引用我的话。 - Jamie Wright

在我的经验中，对于csla的支持很靠运气。只有两个人支持它：Rocky 和 Jonny。我的问题有时可以得到立即解答，但有些问题几个月仍没有回复。请看这个问题http://stackoverflow.com/questions/28330892/cslamodelbinder-not-binding-child-list，我曾在csla网站上问过同样的问题，但没有任何回应。一定要阅读建议的读物——那本书，这样您才能更好地理解。该框架对我来说非常有效，但是在使用之前我已经读了那本书。 - ARs

CSLA是一个业务对象框架，它允许您在数据层之上轻松创建业务对象。它使您能够使用坚实的面向对象原则和良好的关注点分离来设计应用程序。使用它的好处是可以更加高效地开发业务对象，并且可以提高代码的可维护性和可扩展性。 - anaval

显示剩余3条评论

6

我建议阅读什么是CSLA？页面，并浏览CSLA .NET FAQ网站了解更多信息。如需最新发表的信息，请查看使用CSLA 4电子书系列。请注意，内容中的HTML标签已保留。

- Rockford Lhotka

1

CSLA .NET几年前已经迁移到GitHub - 现在的主页是http://cslanet.com。 - Rockford Lhotka

6

作为对@radarbob https://dev59.com/x3M_5IYBdhLWcg3wyWOt#10922373的回复，希望我不会因此引发争论。我们团队一直在使用CSLA开发一些LOB应用程序。从我的经验来看，使用CSLA编写绿地应用程序和维护现有代码，以下是我的回答：

BO不能自行进行数据持久化，您需要一个工厂来处理所有数据持久化，例如使用ORM映射到稍后保存的模型。
很遗憾听到这个消息，我确保学习框架文档并在提交现有代码数据库之前编写至少一个玩具应用程序。此外，您甚至可以下载并浏览CSLA代码。
您有BO->门户->工厂，这不应该很复杂，现有的CSLA示例可以很好地解释每个级别发生了什么。
CLSA永远不应与ORM混淆。
正如您所应该的那样，业务对象很少映射到一个表，并且因此在保存时需要进行一些工作。如果它们映射到一个表中，则可以使用AutoMapper将BO映射到POCO中的1行。
研究CSLA命令，同时没有任何限制使您保持BO的大小或大小不同，只要记住它们与您将持久化的POCO不同即可。

在我们开发的一个项目中，我们能够轻松测试BO以确保业务逻辑是正确的。由于关注点的良好分离，我们单独测试了工厂，以确保业务对象将得到相应的持久化。

有一次，我能够轻松地将我的BO的部分持久化到MongoDB中，因此应用程序在混合数据库MSSQL和MongoDB上运行，而无需甚至更改我的业务对象中的一行代码，我所需要做的就是更新工厂以使用Mongo而不是当前的ORM。

希望这个回答公正地回答了您所有问题。

问候

- Calin

2

CSLA: 基于组件的可扩展逻辑架构

网站上对CSLA的简要描述如下：

CSLA .NET使您能够创建一个面向对象的业务层，抽象和封装了您的业务逻辑和数据。该框架确保您的业务对象与所有.NET接口技术（包括WinRT XAML、WPF、ASP.NET MVC、ASP.NET Web Forms、WCF、asmx服务、Windows Phone 7、Silverlight、Windows Workflow和Windows Forms）无缝协作。

你为什么要使用它：

业务规则管理。一旦您学习了业务规则系统，它提供了一种整洁的方式来执行业务逻辑。如果您有一个带有子对象的对象需要向父级报告验证结果，则有一种处理方法。（有关规则系统的更多信息，请参见http://www.lhotka.net/weblog/CSLA4BusinessRulesSubsystem.aspx）

您有需要支持N级撤消的业务对象吗？CSLA BusinessBase具有内置的属性管理系统（类似于依赖属性），可以实现N级撤消功能（实际上完全实现了）。（这也与业务规则管理相关。您可以在主属性更改时触发验证，或者根据另一个属性的值更改属性。）

数据门户管理。这是一个有趣的概念。如果我需要在本地执行数据操作，则CSLA已经为此进行了配置。我还可以启动引用我的业务对象库的WCF服务，并使用几行配置来创建WCF端点以管理数据操作。WCF服务是CSLA框架的一部分。看到这一点真是太棒了。其他情况？当然！您的业务对象库不需要更改，DataPortal类会根据您的配置确定是否需要远程或本地执行。

CSLA确实强制使用一些机制，这些机制可能一开始并不自然。我认为这在实现任何模式时都是有些真实的。但是，在实现面向服务的架构的挑战方面，CSLA提供了很多东西。是的，你需要让一位架构师级别的开发人员编写一些库。但是，如果您正在构建企业级应用程序，那么您难道不应该已经这样做了吗？

正确设计的CSLA是可测试的。我们使用存储库模式来替换实际的dal，并通过规范（使用NUnit / SpecFlow）和适当的单元方式进行测试。

至于支持，包括Rocky本人，有许多贡献者社区确保像CSLA.Net for Xamarin这样的东西成为现实。有一些咨询公司了解CSLA并根据工作范围定期使用它（不仅仅是我工作的咨询公司）。

综合考虑，CSLA可能不适合你。就像其他人指出的那样，阅读网站和书籍（特别是《Expert C# 2008 Business Objects》）。提出问题，因为CSLA社区倾向于提供高质量的建议。

- Todd Richardson

1

差点为把你的分数从投票时的强迫症友好型999改变到那个丑陋的1009而感到内疚。 - daniloquio

1

关于CSLA的详细描述请参见这里。新书籍是一个很好的起点。作为书籍的绝佳补充，我建议您查看我们的CSLA 3.8模板。Rocky推荐使用代码生成器，而我们拥有领先的一套模板，可以让您快速上手。

谢谢 -Blake Niemyjski（CodeSmith CSLA Templates作者）

- Blake Niemyjski

网页内容由stack overflow 提供, 点击上面的

可以查看英文原文，
原文链接

- radarbob · Accepted Answer

通过我使用一个1.7M行代码库的经验得出的看法:

CSLA用于分布式应用程序/数据库环境。这就是为什么基本业务对象是并且可以执行所有操作，例如自己的数据持久性。一个对象（以及与其状态有关的所有远程内容）旨在被序列化，发送到不同的应用程序和/或数据服务器并工作。
如果以上不是您需要解决的问题，那么CSLA就是过度设计了。我们的开发团队后悔承诺要使用CSLA。
在复杂的窗口化UI中，协调所有CSLA组件很难。我们有多个选项卡屏幕（可能会打开子屏幕），除非您按照“从左到右，从上到下”的数据输入流程进行操作，并频繁点击保存按钮，否则会导致向/从数据库获取不完整的数据；或者丢失您刚刚输入的数据。是的，我们最初的编码人员有错，但CSLA也有责任...似乎有太多移动的部件需要启用、控制和协调CSLA功能。这就像处理战斗机所有的按钮和开关一样，而你真正需要的是类似Cessna 152那样的东西。
您需要编写大量自定义代码来启用CSLA功能。例如，CSLA永远不会与对象关系映射器（ORM）工具（如Hibernate和Entity Framework）混淆。我们的SAVE()方法很复杂，而且那些看起来简单的方法也是如此。
使用代码生成器会带来更多问题。我们使用CodeSMith从数据表中生成类。因此，我们得到的代码具有表到C#类的1:1对应关系。因此，您必须编写所有处理数据存储到“真实”对象的代码。

使用CSLA存储和获取数据非常低效。由于巨兽般的、以BusinessObject为中心的单体范式，对象最终会进行逐个数据获取和实例化。组合对象集合会大大加剧这个问题。单个“获取此对象”始终会导致一连串独立数据获取（每个对象一个或多个）以实例化整个继承和组合关系链。这被称为“N + 1查询问题”。哦，而且获取数据总是导致创建新对象，即使我们只更新现有对象也是如此。难怪我们的更复杂的屏幕都乱糟糟的。

它允许您使用坚实的面向对象原则和良好的关注点分离来设计应用程序。

是与否。主要是否。

BusinessObject处理自己的数据存储。这是反对关注点分离的。

“它允许您...” 好吧，是的 - 空白文本编辑器屏幕也是，但不像例如MVC.NET框架那样强制或鼓励您。在我看来，CLSA绝对没有确保您使用它开发的代码遵循“坚实的OO原则”的任何好处。实际上，弱OO技能的编码人员（在我的经验中占大多数）使用CSLA时真的会很突出！维护程序员要小心。

CSLA是坚实的面向对象原则中“优先组合而非继承”的代表。CLSA代码不可测试。由于继承的框架BusinessObject既是、又是、需要一切，每次都是这样，所以不太可能得到很高的测试覆盖率。您无法获得部件，因为所有东西都紧密耦合。该框架不适合依赖注入。它是一道钢铁之幕。

您的代码将难以调试。调用堆栈变得非常深，当您接近太阳的中心时，一切都变成了反射 - “哪些方法刚刚被调用了????” 然后您就会迷失，没有办法。

编辑 2016年3月7日

我在原帖后还能补充什么更深入的见解呢？也许有两件事：

首先，CSLA似乎具有一定的前途。只要我们知道如何将所有这些组成部分一起协调起来。但是，CSLA是如此神秘，以至于即使我们做得很对的事情随着时间的推移也会变得不好。依我之见，如果没有一个非常强大的团队范围的CSLA基础，任何实现都注定要失败。如果没有一个充满活力的技术参考、培训和社区的“开源”，那就没有希望了。在近十年中，我的最终分析是，我们的CSLA代码只在增加技术债务。

其次，这里有我最近发表的评论：

我们的复杂性通常似乎不适合CSLA架构，因此我们在框架之外进行编写。这和廉价劳动力导致 SRP 违规猖獗，并导致我在管理动态规则应用程序时遇到了瓶颈。然后，CSLA父/子架构会传播组合对象验证，但我们并不总是想要c/p关系，所以我们编写更多的验证和存储代码。所以今天我们的CSLA实现是不一致和令人困惑的。重构为更好的CSLA将产生深远的连锁反应。因此，在那个最初的注入之后，CSLA基本上被放弃了。

编辑完毕