什么是 CSLA 框架及其用途?
6 回答
我的经验来自我的意见,带有 1.7M LOC 代码库:
- CSLA 旨在用于分布式应用程序/数据库环境。这就是为什么基本业务对象是并且做所有事情的原因,例如它自己的数据持久性。一个对象(以及与其状态远程关联的所有内容)旨在被序列化,发送到不同的应用程序和/或数据服务器并工作。
- 如果以上不是您需要解决的问题,CSLA 就大材小用了。我们的开发团队对致力于 CSLA 感到遗憾。
- 在复杂的窗口 UI 中处理所有 CSLA 球是很困难的。我们有多标签屏幕(这可能反过来打开子屏幕),除非您遵循“从左到右,从上到下”的数据输入流程,并经常单击保存,否则最终会放置和/或获取不完整的数据到/从数据库;或完全删除您刚刚输入的数据。是的,我们最初的编码员有问题,但 CSLA 也有问题……似乎有很多活动部件需要启用、控制和协调 CSLA 功能。当你真正需要的是更像塞斯纳 152 的东西时,这就像不得不处理战斗机的所有刻度盘和开关一样。
- 您将编写大量自定义代码来启用 CSLA 功能。例如,CSLA 永远不会与 Hibernate 和 Entity Framework 等对象关系映射器 (ORM) 工具相混淆。我们的 SAVE() 方法是非平凡的,平凡的也是如此。
- 鼓励使用代码生成器会加剧问题。我们使用 CodeSMith 从数据表中生成类。因此,我们最终得到的代码具有表与 c# 类的 1-1 对应关系。所以你必须编写所有代码来处理你的“真实”对象的数据存储。
- 使用 CSLA 时,数据存储/和获取效率非常低。由于是庞然大物,以 BusinessObject-does-all-and-knows-all 为中心的整体范式,对象最终会执行一次一个对象的数据获取和实例化。复合对象的集合显着地使问题复杂化。单个“获取此对象”总是会导致一系列单独的数据获取(每个单独的对象一个或多个)以实例化整个继承和复合关系链。它被称为“N+1 查询问题”。哦,获取数据总是会导致创建一个新对象,即使我们只是更新一个现有的对象。难怪我们更复杂的屏幕是 FUBAR。
它允许您使用可靠的面向对象原则和良好的关注点分离来构建您的应用程序。
是和不是。大多数情况下没有。
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 基本上被放弃了。
结束编辑
CSLA 是业务对象框架,可让您轻松地在数据层之上创建业务对象。它允许您使用可靠的面向对象原则和良好的关注点分离来构建您的应用程序。
我强烈建议您阅读 Rocky Lhotka 的 CSLA 书,名为 Expert C# 2008 Business Objects。这不仅会教你有关框架的知识,还会教你好的软件架构原则。
回复@radarbob https://stackoverflow.com/a/10922373/261363,希望我不会后悔并开始一场火焰战。
我们的团队一直在使用 CSLA 开发几个 LOB 应用程序。根据我使用 CSLA 编写绿地应用程序和维护现有代码的经验,这是我对您的观点的答复。
BO 不应该做自己的数据持久性,您将拥有一个工厂来处理所有数据持久性,例如使用 ORM 映射到稍后保存的模型。
很遗憾听到这个消息,在提交到现有代码数据库之前,我确保我研究了框架文档并编写了至少一个玩具应用程序。此外,您甚至可以下载和浏览 CSLA 代码。
你有 BO -> 门户 -> 工厂,它们不应该很复杂,现有的 CSLA 示例在解释每个级别上发生的事情方面大有帮助。
CLSA 绝不应与 ORM 混淆
正如您应该做的那样,业务对象很少映射到一个表,因此在保存时需要做一些工作。如果它们被映射到一个表,您可以使用 AutoMapper 之类的东西将您的 BO 映射到 1 行中的 POCO。
查看 CSLA 命令,也没有什么能阻止您将您的 BO 保持在您想要的大小,只要您记住它们与您将坚持的 POCO 不同。
在我们从事的一个项目中,我们能够轻松地测试 BO 以确保业务逻辑是正确的。由于良好的关注点分离,我们单独测试了我们的工厂,以确保业务对象将相应地持久化。
在某一时刻,我能够轻松地将部分 BO 保存在 MongoDB 中,因此应用程序在混合数据库 MSSQL 和 MongoDB 上运行,甚至无需更改业务对象中的一行代码,我所要做的就是更新工厂使用 Mongo 而不是当前的 ORM。
希望这能以公平的方式解决您的所有观点,
问候
我建议阅读什么是 CSLA?页面,并浏览CSLA .NET FAQ 站点。
有关最新发布的信息,请查看使用 CSLA 4 电子书系列。
CSLA:基于组件的可扩展逻辑架构
简而言之,从网站上向我描述 CSLA 的一段话是这样的:
CSLA .NET 使您能够创建一个抽象和封装业务逻辑和数据的面向对象的业务层。该框架可确保您的业务对象与所有 .NET 接口技术无缝协作,包括 WinRT XAML、WPF、ASP.NET MVC、ASP.NET Web 窗体、WCF、asmx 服务、Windows Phone 7、Silverlight、Windows 工作流和 Windows 窗体。
为什么你可能会使用它:
业务规则管理。一旦您学习了业务规则系统,它就提供了一种在一个整洁的包中强制执行业务逻辑的方法。如果您有一个带有子对象的对象需要向父级报告验证,那么有一种方法可以处理它。(有关规则系统的更多信息,请参见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 社区倾向于提供高质量的建议。
此处详细描述了 CSLA 。新书是一个很好的起点。作为对本书的极大赞美,我建议您查看我们的CSLA 3.8 模板。Rocky 建议使用代码生成器,我们拥有领先的模板集,可以让您立即启动并运行。
谢谢 -Blake Niemyjski(CodeSmith CSLA 模板的作者)