什么是CSLA框架及其使用？

Question

什么是CSLA框架及其使用？

Answer 1

来自我的经验的我的意见,带有1.7M LOC代码库:

1. CSLA适用于分布式应用程序/数据库环境.这就是基本业务对象是并且做所有事情的原因,例如它自己的数据持久性.一个对象(以及与其状态远程关联的所有内容)旨在被序列化,发送到不同的应用程序和/或数据服务器并工作.
2. 如果上述问题不是你需要解决的问题,那么CSLA就是过度杀伤力的.我们的开发团队对已经致力于CSLA感到遗憾.
3. 在复杂的Windowed UI中处理所有CSLA球是很困难的.我们有多标签屏幕(可以依次打开子屏幕),除非你按照"从左到右,从上到下"的数据输入流程,并经常点击保存,最终放入和/或提取不完整的数据往返数据库; 或者完全删除您刚刚输入的数据.是的,我们的原始编码器有问题,但CSLA也是如此......似乎有很多移动部件可以启用,控制和协调CSLA功能.这就像必须处理战斗机的所有拨号和开关一样,当你真正需要的东西更像是塞斯纳152.
4. 您将编写大量自定义代码以启用CSLA功能.例如,CSLA永远不会与Hibernate和Entity Framework等对象关系映射器(ORM)工具混淆.我们的SAVE()方法非常简单,琐碎的方法也是如此.
5. 鼓励使用代码生成器复杂化问题.我们使用CodeSMith从数据表生成类.因此,我们最终得到的代码具有1-1到c#类的对应关系.因此,您必须编写所有代码来处理dataStore到您的"真实"对象.
6. 使用CSLA进行数据存储/获取效率非常低.由于Behemoth,单片BusinessObject-all-all-and-known-all中心范例,对象最终会进行一次一对象的数据获取和实例化.复合对象的集合显着地使问题复杂化.单个"获取此对象"始终会导致一系列单独的数据提取(每个单独对象一个或多个)以实例化整个继承和复合关系链.它被称为"N + 1查询问题".哦,并且获取数据总是导致创建一个新对象,即使我们只是更新现有对象.难怪我们更复杂的屏幕是FUBAR.

它允许您使用可靠的面向对象的主体和良好的关注点来构建您的应用程序.

是的,不是.绝大多数没有.

BusinessObject处理它自己的数据存储.这是关注的反分离.

"它允许你......"嗯,是的 - 一个空白的文本编辑器屏幕也是如此,但是并不像MVC.NET框架那样强迫或鼓励你.恕我直言,里昂证券提供绝对零利益,以确保您使用它开发的代码遵循"坚实的OO原则".事实上,在使用CSLA时,具有弱OO技能的编码员(根据我的经验,大多数人)会非常突出!祸好维护程序员.

CSLA是坚定的面向对象原则的 代表性,有利于构成而不是继承. CLSA代码是不可测试的.因为继承的框架BusinessObject既是,也是,并且需要所有内容,所有这些都是一次又一次,所以您不可能获得更多的测试覆盖率.你无法理解,因为一切都紧密耦合.框架不适合依赖注入.这是代码的铁幕.

您的代码将难以调试.调用堆栈变得非常深,当你靠近太阳的中心时可以说,一切都变成了反射 - "什么*&^#方法被称为???" 而你只是迷路了.期.

编辑2016年3月7日

我可以在原帖后添加更多见解吗？两件事,也许是:

首先,感觉 CSLA有一些承诺.如果我们知道如何将所有这些活动部件放在一起.但CSLA是如此神秘,即使我们做得对的事情也会随着时间的推移而受到损害.恕我直言,没有一个非常强大的团队CSLA资金,任何实施都注定失败.没有充满活力的技术参考,培训和社区的"开源",它就没有希望了.近十年来,我的CSLA代码,归根结底,只是复合技术债务.

其次,这是我最近的评论,如下:

我们的复杂性通常似乎不适合CSLA基础架构,因此我们在框架之外编写.例如,这种廉价的劳动力导致SRP违规行为猖獗,并让我在砖墙上管理动态规则应用程序.然后,CSLA父/子基础结构传播复合对象验证,但我们并不总是想要c/p关系,因此我们编写更多验证和存储代码.所以今天我们的CSLA实施是不一致和混乱的.重构为更好的CSLA将产生深刻的多米诺骨牌效应.因此,在初始注射后,CSLA基本上被放弃了.

结束编辑

Answer 2

CSLA是业务对象框架,允许您在数据层之上轻松创建业务对象.它允许您使用可靠的面向对象的主体和良好的关注点来构建您的应用程序.

我强烈建议你阅读Rocky Lhotka撰写的名为Expert C#2008 Business Objects的CSLA书.这不仅可以教你如何构建框架,还可以教授优秀的软件架构原理.

你可以在亚马逊上找到这本书

Answer 3

我建议阅读什么是CSLA？页，然后浏览CSLA .NET FAQ网站。

有关最新发布的信息，请查看《使用CSLA 4》电子书系列。

Answer 4

回复@radarbob /sf/answers/764566141/，希望我不会后悔并开始火焰战争。

Our team has been developing a couple of LOB applications with CSLA. From my experience on writing green field apps with CSLA and maintaining existing code here are my replies to your points.

1. The BO is not suppose to do it's own data persistence, you will have a Factory that will handle all data persistance, for example using a ORM to map to Models that are later on saved.

2. Sorry to hear that, I make sure I study the framework documentation and write at least one toy application before committing to a existing code database. Furthermore you can even download and browse the CSLA code.

3. You have BO -> Portal -> Factories that should not be very complicated the existing CSLA examples go a long way on explaining what is happening on each level.

4. CLSA should never be confused with a ORM

5. As you should, business object are rarely mapped to one table and thus require a bit of work when saving. In the case they are mapped to one table to you use something like AutoMapper to map your BO to your POCO in 1 line.

6. Look into CSLA Commands, also is nothing stopping you from keeping your BO as small or big as you want as long as you keep in mind that they are not the same as the POCO's that you will persist.

In a project we worked on we where able to easily test BO to ensure that the business logic was correct. Because of the nice separation of concerns we tested our Factories in isolation to make sure that business objects will be persisted accordingly.

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

希望这能以公平的方式解决您的所有问题，

问候