A paragraph in a nutshell that described CSLA to me from the website was this:
CSLA .NET enables you to create an object-oriented business layer that abstracts and encapsulates your business logic and data. The framework ensures your business objects work seamlessly with all .NET interface technologies, including WinRT XAML, WPF, ASP.NET MVC, ASP.NET Web Forms, WCF, asmx services, Windows Phone 7, Silverlight, Windows Workflow and Windows Forms.
Why you might use it:
Business rule management. Once you learn the business rule system, it provides a way to enforce business logic in a tidy package. If you have an object with child objects that need to report Validation to the parent most level, there is a way to handle that. (see http://www.lhotka.net/weblog/CSLA4BusinessRulesSubsystem.aspx for more information on the rule system)
You have business objects that you need to support N-level undo? A CSLA BusinessBase has a baked in property management system (like dependency properties) for functionality like N-Level Undo (it is actually completely implemented.) (This also ties into the business rule management. You can fire validation when a primary property changes, or you can change a property based on the value of another property.)
Data portal management. This one was an interesting concept. If I need to execute data operations locally, CSLA is configured for this out of the box. I can also stand up a WCF service that references my business object libraries, and use a few lines of configuration to make a WCF endpoint to manage data operations. The WCF service is a part of the CSLA framework. It was neat to see this in action. Other scenarios? Sure! Your business object library doesn't need to change, the DataPortal class determines if it needs to execute remotely or locally, according to your configuration.
CSLA does force you to use a few mechanisms that may not feel natural at first. I think that is somewhat true of any pattern you choose to implement. However, when it comes to the challenges of implementing Service Oriented Architecture, CSLA offers a lot. Yes, you are going to have an architect level developer authoring some of your libraries. However, if you're building an enterprise class application, shouldn't you be doing that already?
CSLA, when architected correctly, is testable. We use the repository pattern to replace out the actual dal with a mock layer and test both by specification (using NUnit/SpecFlow) and in a unit fashion when appropriate.
As far as support, including Rocky himself, there is a community of contributors that ensure things like CSLA.Net for Xamarin become a reality. There are consultancies that know CSLA and use it on a regular basis depending on the scope of work (and no, not just the consultancy for which I work.)
All things considered, CSLA may not be for you. Like others have indicated, read the site and the books (especially Expert C# 2008 Business Objects.) Ask questions, as the CSLA community tends to give quality advice.
CSLA is described in detail here. The new book is a great starting point. As a great compliment to the book I would recommend checking out our CSLA 3.8 templates. Rocky recommends using a Code Generator, and we have the leading set of templates, that will get you up and running in no time.
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.
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.
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.
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.
CLSA should never be confused with a ORM
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.
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.
At one point I was able to easily persist part of my BO's in MongoDB so the application was running on a hybrid database MSSQL and MongoDB without having to even change one line of code in my business objects, all I had to do was to update the factories to use Mongo instead of the current ORM.
Hope this addresses all your points in a fair manner,
My Opinions From My Experience w/ a 1.7M LOC code base:
CSLA is intended for a distributed application/database environment. This is why the basic business object is and does everything, for example it's own data persistence. An object (and everything remotely associated w/ its state) is intended to be serialized, sent to a different application and/or data server and work.
If the above is not a problem you need to solve, CSLA is overkill, big time. Our development team regrets having committed to CSLA.
Juggling all the CSLA balls in a complex Windowed UI is tough. We have multi-tabbed screens (which may in turn open sub-screens) that, unless you follow the "left to right, top to bottom" flow of data entry, and click save often, ends up putting and/or fetching incomplete data to/from the database; or dropping data altogether that you just entered. Yes, our original coders are at fault, but so is CSLA... It just seems that there are so many moving parts to enable, control, and coordinate CSLA features. It's like having to deal with all the dials & switches of a fighter jet when all you really need is something more like a Cessna 152.
You will write lots of custom code to enable the CSLA features. For example CSLA will never be confused with object relational mapper (ORM) tools like Hibernate and Entity Framework. Our SAVE() methods are non trivial, so are the trivial ones.
Encouraging the use of code generators compounds problems. We used CodeSMith to generate classes from data tables. So we end up with code that has a 1-1 correspondence of table to c# class. So you must write all the code to handle dataStore to your "real" objects.
Data store/ and fetch is very inefficient w/ CSLA. Because of the Behemoth, monolithic BusinessObject-does-all-and-knows-all centric paradigm, objects end up doing a one-object-at-a-time data fetch and instantiate. Collections of composite objects significantly compound the problem. A single "get this object" always results in a cascade of separate data fetches (one or more for each individual object) to instantiate the entire inheritance & composite relationship chains. Its known as the "N+1 query problem." Oh, and fetching data ALWAYS results in a new object being created, even if we're only updating an existing one. No wonder our more complex screens are FUBAR.
It allows you to architect your application with solid object oriented principals and a good seperation of concerns.
Yes and no. Mostly no.
The BusinessObject handles it's own data storing. That is anti separation of concerns.
"It allows you..." well, yeah - so does a blank text editor screen, but does not force or encourage you like the MVC.NET framework does, for example. IMHO, CLSA provides absolutely zero benefit for ensuring that the code you develop with it follows "solid OO principles". In fact coders w/ weak OO skills (the majority, in my experience) will really stand out when using CSLA! Woe betide the maintenance programmer.
CSLA is the poster child for the solid object oriented principle favor composition over inheritance. CLSA code is untestable. Because an inherited framework BusinessObject is, does, and needs everything, all at once and every time, it's not likely that you will be able to get much test coverage. You can't get at the pieces because everything is tightly coupled.The framework is not amenable to dependency injection. It is an iron curtain of code.
Your code will be difficult to debug. Call stacks get very deep and as you get near the center of the sun so to speak, everything turns into reflection - "what *&^# methods just got called???" And you simply get lost. period.
EDIT 7 Mar 2016
What more insight can I add after the original post? Two things, perhaps:
First, It feels like CSLA has some promise. If we knew how to juggle all those moving parts together. But CSLA is so enigmatic that even things we have done right are corrupted over time. IMHO without a very strong team-wide CSLA wherewithal, any implementation is doomed. Without a vibrant "open source" of technical references, training, and community it's hopeless. In almost a decade our CSLA code, in my final analysis, is just compounding technical debt.
Second, here is a recent comment I made, below:
Our complexity often does not seem to fit in the CSLA infrastructure so we write outside of the framework. This and cheap labor results in rampant SRP violations and has me hitting brick walls managing dynamic rule application, for example. Then, CSLA parent/child infrastructure propagates composite object validation but we don't always want c/p relationships, so we write more validation and store code. So today our CSLA implementation is inconsistent & confusing. Refactoring to more-better CSLA will have profound domino effects. So after that initial injection CSLA is essentially abandoned.
CSLA is business object framework that allows you to easily create business objects on top of a data layer. It allows you to architect your application with solid object oriented principals and a good seperation of concerns.
I would highly recommend you read the CSLA book by Rocky Lhotka called Expert C# 2008 Business Objects. That will not only teach you about the framework but also teach good software architecture principals.
发布评论
评论（6）
CSLA：基于组件的可扩展逻辑架构
网站上向我描述 CSLA 的一段简而言之是：
为什么你可能会使用它：
业务规则管理。 一旦您学习了业务规则系统，它就提供了一种在整洁的包中强制执行业务逻辑的方法。 如果您有一个带有子对象的对象需要向最高级的父对象报告验证，则有一种方法可以处理该问题。 （有关详细信息，请参阅 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: Component-based Scalable Logical Architecture
A paragraph in a nutshell that described CSLA to me from the website was this:
Why you might use it:
Business rule management. Once you learn the business rule system, it provides a way to enforce business logic in a tidy package. If you have an object with child objects that need to report Validation to the parent most level, there is a way to handle that. (see http://www.lhotka.net/weblog/CSLA4BusinessRulesSubsystem.aspx for more information on the rule system)
You have business objects that you need to support N-level undo? A CSLA BusinessBase has a baked in property management system (like dependency properties) for functionality like N-Level Undo (it is actually completely implemented.) (This also ties into the business rule management. You can fire validation when a primary property changes, or you can change a property based on the value of another property.)
Data portal management. This one was an interesting concept. If I need to execute data operations locally, CSLA is configured for this out of the box. I can also stand up a WCF service that references my business object libraries, and use a few lines of configuration to make a WCF endpoint to manage data operations. The WCF service is a part of the CSLA framework. It was neat to see this in action. Other scenarios? Sure! Your business object library doesn't need to change, the DataPortal class determines if it needs to execute remotely or locally, according to your configuration.
CSLA does force you to use a few mechanisms that may not feel natural at first. I think that is somewhat true of any pattern you choose to implement. However, when it comes to the challenges of implementing Service Oriented Architecture, CSLA offers a lot. Yes, you are going to have an architect level developer authoring some of your libraries. However, if you're building an enterprise class application, shouldn't you be doing that already?
CSLA, when architected correctly, is testable. We use the repository pattern to replace out the actual dal with a mock layer and test both by specification (using NUnit/SpecFlow) and in a unit fashion when appropriate.
As far as support, including Rocky himself, there is a community of contributors that ensure things like CSLA.Net for Xamarin become a reality. There are consultancies that know CSLA and use it on a regular basis depending on the scope of work (and no, not just the consultancy for which I work.)
All things considered, CSLA may not be for you. Like others have indicated, read the site and the books (especially Expert C# 2008 Business Objects.) Ask questions, as the CSLA community tends to give quality advice.
此处详细描述了 CSLA。 新的书是一个很好的起点。 作为对本书的高度赞扬，我建议您查看我们的CSLA 3.8 模板 。 Rocky 建议使用代码生成器，我们拥有领先的模板集，可以让您立即启动并运行。
谢谢
-Blake Niemyjski（CodeSmith CSLA 模板 的作者）
CSLA is described in detail here. The new book is a great starting point. As a great compliment to the book I would recommend checking out our CSLA 3.8 templates. Rocky recommends using a Code Generator, and we have the leading set of templates, that will get you up and running in no time.
Thanks
-Blake Niemyjski (Author of the CodeSmith CSLA Templates)
回复@radarbob https://stackoverflow.com/a/10922373/261363，希望我不会后悔并开始一场火焰战争。
我们的团队一直在使用 CSLA 开发几个 LOB 应用程序。 根据我使用 CSLA 编写新应用程序和维护现有代码的经验，这里是我对您的观点的答复。
BO 不应该做它自己的数据持久性，您将有一个工厂来处理所有数据持久性，例如使用 ORM 映射到稍后保存的模型。
很抱歉听到这个消息，我确保在提交到现有代码数据库之前研究框架文档并至少编写一个玩具应用程序。 此外，您甚至可以下载并浏览 CSLA 代码。
你有BO -> 传送门-> 工厂不应该太复杂，现有的 CSLA 示例在解释每个级别上发生的事情方面有很大帮助。
CLSA 永远不应该与 ORM 混淆
正如您所应该的，业务对象很少映射到一个表，因此在保存时需要一些工作。 如果它们映射到一个表，您可以使用 AutoMapper 之类的工具在一行中将您的 BO 映射到 POCO。
正如
在我们从事的一个项目中，我们能够轻松地测试 BO 以确保业务逻辑是正确的。 由于关注点的良好分离，我们单独测试了我们的工厂，以确保业务对象能够相应地持久化。
有一次，我能够轻松地将我的 BO 的一部分保留在 MongoDB 中，因此应用程序在混合数据库 MSSQL 和 MongoDB 上运行，甚至无需更改业务对象中的一行代码，我所要做的就是更新工厂使用 Mongo 而不是当前的 ORM。
希望这能以公平的方式解决您的所有问题，
问候
In reply to @radarbob https://stackoverflow.com/a/10922373/261363, hope I won't regret this and start a flame war.
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.
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.
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.
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.
CLSA should never be confused with a ORM
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.
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.
At one point I was able to easily persist part of my BO's in MongoDB so the application was running on a hybrid database MSSQL and MongoDB without having to even change one line of code in my business objects, all I had to do was to update the factories to use Mongo instead of the current ORM.
Hope this addresses all your points in a fair manner,
Regards
根据我使用 1.7M LOC 代码库的经验得出的观点：
是和不是。 大多没有。
BusinessObject 处理它自己的数据存储。 这是反关注点分离的。
“它允许你......”好吧，是的 - 空白文本编辑器屏幕也是如此，但不会像 MVC.NET 框架那样强制或鼓励你。 恕我直言，里昂证券为确保您使用它开发的代码遵循“可靠的面向对象原则”提供了绝对零的好处。 事实上，面向对象技能较弱的程序员（根据我的经验，大多数）在使用 CSLA 时会真正脱颖而出！ 维护程序员有祸了。
CSLA 是面向对象原则的典型代表，优先考虑组合而不是继承。 CLSA 代码是不可测试的。 因为继承的框架 BusinessObject 是、确实并且每次都需要一切，所以您不太可能获得太多的测试覆盖率。 您无法了解各个部分，因为一切都是紧密耦合的。该框架不适合依赖项注入。 这是代码的铁幕。
您的代码将很难调试。 调用堆栈变得非常深，可以这么说，当您接近太阳中心时，一切都会变成反射 - “刚刚调用了什么 *&^# 方法？？？” 你就会迷路。 时期。
编辑 2016 年 3 月 7 日
在原始帖子之后我还可以添加哪些更多见解？ 也许有两件事：
首先，感觉 CSLA 有一些希望。 如果我们知道如何将所有这些活动部件组合在一起。 但 CSLA 是如此神秘，以至于即使我们做得正确的事情也会随着时间的推移而被破坏。 恕我直言，如果没有非常强大的团队范围的 CSLA 资金，任何实施都注定会失败。 如果没有充满活力的“开源”技术参考、培训和社区，一切都是没有希望的。 在我的最终分析中，近十年来我们的 CSLA 代码只是在加剧技术债务。
其次，这是我最近发表的评论，如下：
结束编辑
My Opinions From My Experience w/ a 1.7M LOC code base:
Yes and no. Mostly no.
The BusinessObject handles it's own data storing. That is anti separation of concerns.
"It allows you..." well, yeah - so does a blank text editor screen, but does not force or encourage you like the MVC.NET framework does, for example. IMHO, CLSA provides absolutely zero benefit for ensuring that the code you develop with it follows "solid OO principles". In fact coders w/ weak OO skills (the majority, in my experience) will really stand out when using CSLA! Woe betide the maintenance programmer.
CSLA is the poster child for the solid object oriented principle favor composition over inheritance. CLSA code is untestable. Because an inherited framework BusinessObject is, does, and needs everything, all at once and every time, it's not likely that you will be able to get much test coverage. You can't get at the pieces because everything is tightly coupled.The framework is not amenable to dependency injection. It is an iron curtain of code.
Your code will be difficult to debug. Call stacks get very deep and as you get near the center of the sun so to speak, everything turns into reflection - "what *&^# methods just got called???" And you simply get lost. period.
EDIT 7 Mar 2016
What more insight can I add after the original post? Two things, perhaps:
First, It feels like CSLA has some promise. If we knew how to juggle all those moving parts together. But CSLA is so enigmatic that even things we have done right are corrupted over time. IMHO without a very strong team-wide CSLA wherewithal, any implementation is doomed. Without a vibrant "open source" of technical references, training, and community it's hopeless. In almost a decade our CSLA code, in my final analysis, is just compounding technical debt.
Second, here is a recent comment I made, below:
end Edit
CSLA 是业务对象框架，允许您在数据层之上轻松创建业务对象。 它允许您使用可靠的面向对象原则和良好的关注点分离来构建您的应用程序。
我强烈建议您阅读由 Rocky Lhotka 编写的 CSLA 书籍 Expert C# 2008 Business Objects。 这不仅会教您有关框架的知识，还会教您良好的软件架构原理。
您可以在 Amazon 上获取这本书
CSLA is business object framework that allows you to easily create business objects on top of a data layer. It allows you to architect your application with solid object oriented principals and a good seperation of concerns.
I would highly recommend you read the CSLA book by Rocky Lhotka called Expert C# 2008 Business Objects. That will not only teach you about the framework but also teach good software architecture principals.
You can grab the book here on Amazon
我建议阅读 什么是 CSLA？ 页面，并浏览 CSLA .NET 常见问题解答网站。
有关最新发布的信息，请查看使用 CSLA 4 电子书系列 。
I suggest reading the What is CSLA? page, and browse through the CSLA .NET FAQ site.
For the latest published information check out the Using CSLA 4 ebook series.