有人有 CSLA 的实际经验吗？
我公司的主要 Web 应用程序迫切需要一组漂亮的库，以使其以某种方式可维护和可扩展，我的一位同事建议使用 CSLA。 所以我买了这本书，但是：
程序员不再读书
我想了解 SOFlow 社区对此的看法。
我的问题是：
- 人们如何使用 CSLA？
- 优缺点都有什么？
- CSLA 真的不适合 TDD 吗？
- 我有什么选择？
- 如果您已停止使用它或决定不使用它，为什么？
The main web application of my company is crying out for a nifty set of libraries to make it in some way maintainable and scalable, and one of my colleagues has suggested CSLA. So I've bought the book but as :
programmers don't read books anymore
I wanted to gauge the SOFlow community's opinion of it.
So here are my questions:
- How may people are using CSLA?
- What are the pros and cons?
- Does CSLA really not fit in with TDD?
- What are my alternatives?
- If you have stopped using it or decided against why?
如果你对这篇内容有疑问，欢迎到本站社区发帖提问 参与讨论，获取更多帮助，或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱，如果其他用户或者作者回复了您的评论，将不能在第一时间通知您！
发布评论
评论（23）
几年前我在一个项目中使用了它。 但当项目完成后，我无法告诉任何人 CSLA 为我做了什么。 当然，我继承了它的类。 但我能够从几乎所有类中删除该继承，而无需进行重组。 我们对 N 层的东西没有用处。 n 级撤消速度太慢，我们无法使用它。 所以我想最终它只会帮助我们模拟我们的课程。
话虽如此，其他团队已经开始使用它（在一个团队尝试创建自己的框架的可怕尝试之后）。 所以里面一定有一些有价值的东西，因为他们都比我聪明！
I used it for a project a couple years ago. But when the project was done, I couldn't tell anyone what CSLA did for me. Sure, I inherited from its classes. But I was able to remove that inheritance from almost all classes with no restructuring. We had no use for the N-Tier stuff. The n-level undo was so slow that we couldn't use it. So I guess at the end it only helped us model our classes.
Having said that, other teams have started using it (after a horrid attempt by a team to create their own framework). So there has to be something worthwhile in there, because they're all smarter than me!
很多人建议将代码生成与 CSLA 结合使用。 我建议您查看我们支持的模板集，因为它们将极大地提高您的投资回报率。
谢谢
-Blake Niemyjski（CodeSmith CSLA 模板 的作者）
A lot of people recommend using Code Generation with CSLA. I'd recommend checking out our set of supported templates as they will increase your ROI immensely.
Thanks
-Blake Niemyjski (Author of the CodeSmith CSLA Templates)
我使用 CSLA 作为中型项目的业务对象框架。 该框架自 VB6 时代以来已经走过了很长一段路，提供了非凡的灵活性和“开箱即用”的功能。 CSLA 的移动智能对象使 UI 开发变得更加容易。 然而，我同意其他人的观点，它并不是适合所有情况的正确工具。 肯定会涉及一些开销，但也需要很大的功率。 就我个人而言，我期待将 CSLA Light 与 Silverlight 结合使用。
优点：
缺点
I'm not sure about test driven design. I don't unit test or test driven design (shame on me), so I don't know if unit tests are different than TDD, but I know that the most recent version of the framework comes with unit tests.
1 好事，因为数据访问技术永远不会长期保持不变。
2 最近版本的框架已经变得更好。
I am using CSLA as the business object framework for a medium size project. The framework has come a long way from the VB6 days and offers an extraordinary amount of flexibility and "out of the box" functionality. CSLA's mobile smart objects makes UI development much easier. However, I agree with others it isn't the right tool for every situation. There is definitely some overhead involved, but also a lot of power. Personally, I am looking forward to using the CSLA Light with Silverlight.
Pros:
Cons
I'm not sure about test driven design. I don't unit test or test driven design (shame on me), so I don't know if unit tests are different than TDD, but I know that the most recent version of the framework comes with unit tests.
1 Good thing because data access technologies never stay the same for long.
2 This has gotten better with recent versions of the framework.
我想使用它，但我当时的首席开发人员认为其中涉及太多“魔法”......
I wanted to use it, but my then lead developer had the idea too much 'magic' was involved...
CSLA 是现有的最好的应用程序框架。 洛基·霍特卡（Rocky LHotka）是一个非常聪明的人。 他正在像 Martin Fowler、David S Platt 一样撰写软件开发史，但我最喜欢的作家是 Rod Stephens、Mathew McDonalds、Jeff Levinson、Thearon Willis 和 Louis Davidson（别名 sql 博士）。 :-)
优点：应用了所有设计模式。
缺点：学习困难，样本较少。
CSLA is the best application framework that exists. Rocky LHotka is a very but very smart guy. He is writing the history of software development like Martin Fowler, David S Platt, but my favourites writers are Rod Stephens, Mathew mcDonalds Jeff Levinson thearon willis and Louis Davidson alias dr sql. :-)
Pros: All design patterns are applied.
Cons: Hard to learn, and few samples.
我上次尝试使用 CSLA 是在 VB6 的石器时代。 回想起来，如果我使用代码生成会更有效。 如果您没有有效的代码生成工具以及将它们融入您的工作流程的策略，那么您应该避免使用 CSLA 这样的框架，否则您从 CSLA 获得的功能将无法弥补您花费在编写 n 行代码上的时间每个表的代码数，每列 n 行代码等。
I last tried to use CSLA in the stone age days of VB6. In retrospect, it would have been more effective if I had used code generation. If you don't have effective code generation tools and a strategy for fitting them into your workflow, they you should avoid frameworks like CSLA, otherwise the features you get from CSLA won't make up for the amount of time you spend writing n lines of code per table, n lines of code per column, etc.
我现在已经在几个项目中使用了 CSLA.NET，它在 Windows 窗体应用程序中最为成功，它具有丰富的数据绑定兼容性（asp.net 应用程序没有）。
它的主要问题是 TDD 支持，就像人们指出的那样，这是因为 Dataportal_XYZ 函数的黑盒行为，并且它无法允许我们模拟数据对象。 人们已经努力通过 this< 来解决此问题/a> 是最好的方法
I've used CSLA.NET in few projects now, it was most successfull in a windows forms application which has rich databinding compatabilities (which asp.net application's don't have).
It's main problem is the TDD support like people have been pointing out, this is because of the black-box like behaviour for the Dataportal_XYZ functions and it's inability to allow us to mock the data objects. There have been efforts to work around this issue with this being the best approach
John，
我们有团队在 CSLA 2 到 3.5 中工作，并发现这是提供一致框架的好方法，因此所有开发人员都“以相同的方式做事”。 很高兴大多数低价值代码都是生成的，我们知道当我们运行单元测试时，它们可以开箱即用地处理所有 CRUD 内容。 我们发现我们的 TDD 确实伴随着我们设计时的重构而出现，并且 CSLA 并没有阻止我们做任何这些事情。
克里斯
John,
We have teams working in CSLA from 2 to 3.5 and have found it a great way to provide a consistant framework so all the developers are "doing it the same way". It is great that most of the low value code is generated and we know when we run unit tests they work out of the box for all the CRUD stuff. We find that our TDD really comes in with the refactoring we do to design, and CSLA doesn't prevent us from doing any of that.
Chris
阅读完所有答案后，我发现不少人对 CSLA 存在一些误解。
首先，CSLA 不是 ORM。 我怎么能这么肯定地说呢？ 因为 Rockford Lhotka 在 .NET Rocks 和 Hansel 分钟 播客的采访中多次说过这一点。 寻找任何洛基接受采访的剧集，他都会毫不含糊地陈述这一点。 我认为这是人们需要理解的最关键的事实，因为几乎所有关于 CSLA 的误解都源于相信它是一种 ORM 或试图将其用作一种 ORM。
正如 Brad Leach 在他的回答中提到的那样，CSLA 对象对行为进行建模，尽管更准确的说法是它们对数据的行为进行建模，因为数据是它们不可或缺的一部分。 CSLA 不是 ORM，因为它完全不知道您如何与数据存储交互。 您应该使用某种带有 CSLA 的数据访问层，甚至可能是 ORM。 （我愿意。我现在使用实体框架，它工作得很好。）
现在，进行单元测试。 我在对 CSLA 对象进行单元测试时从未遇到过任何困难，因为我不会将数据访问代码直接放入业务对象中。 相反，我使用存储库模式的一些变体。 存储库由 CSLA 使用，而不是相反。通过为我的单元测试交换一个假存储库并使用本地数据门户，BOOM！这很简单。 （一旦 Entity Framework 允许使用 POCO，这将更加干净。）
所有这一切都来自于认识到 CSLA 不是 ORM。 它可能会消耗一个 ORM，但它本身并不是一个。
干杯。
更新
我想我会再发表一些评论。
有人说，与 LINQ to SQL 等相比，CSLA 过于冗长。 但在这里我们将苹果与橙子进行比较。 LINQ to SQL 是一种 ORM。 它提供了一些 CSLA 所没有的功能，而 CSLA 提供了一些 L2S 所没有的功能，例如通过各种远程数据门户进行集成验证和n层持久性。 事实上，我想说最后一件事，n层的坚持，对我来说胜过一切。 如果我想通过网络使用实体框架或 LINQ to SQL，我必须在两者之间放置类似 WCF 的东西，这会极大地增加工作量和复杂性，以至于我认为它很多比 CSLA 更详细。 （现在，我是 WCF、REST 和 SOA 的粉丝，但是在您真正需要的地方使用它，例如当您想要向第三方公开服务时。对于大多数业务线应用程序来说，它不是事实上，在最新版本的 CSLA 中，Rocky 提供了一个
WCFDataPortal，我已经使用过它。 效果很好。我是 SOLID、TDD 和其他现代软件开发原则的粉丝，并在任何地方使用它们实际的。 但我认为 CSLA 的好处超过了那些正统观点的一些反对意见，并且无论如何，我已经设法使 CSLA 与 TDD 配合得很好（并且很容易），所以这不是问题。
After reading all the answers, I've noticed that quite a few people have some misconceptions about CSLA.
First, CSLA is not an ORM. How can I say that so definitely? Because Rockford Lhotka has stated it himself many times in interviews on the .NET Rocks and Hanselminutes podcasts. Look for any episode where Rocky was interviewed and he'll state it in no uncertain terms. I think this is the most critical fact for people to understand, because almost all the misconceptions about CSLA flow from believing that it is an ORM or attempting to use it as one.
As Brad Leach alluded in his answer, CSLA objects model behavior, although it may be more accurate to say that they model the behavior of data, since data is integral to them. CSLA is not an ORM because it's completely agnostic about how you talk to your data store. You should use some kind of data access layer with CSLA, perhaps even an ORM. (I do. I now use Entity Framework, which works beautifully.)
Now, on to unit testing. I've never had any difficulty unit testing my CSLA objects, because I don't put my data access code directly into my business objects. Instead, I use some variation of the repository pattern. The repository is consumed by CSLA, not the other way around. By swapping in a fake repository for my unit tests and using the local data portal, BOOM! it's simple. (Once Entity Framework allows the use of POCOs, this will be even cleaner.)
All of this comes from realizing that CSLA is not an ORM. It might consume an ORM, but it itself is not one.
Cheers.
UPDATE
I thought I'd make a few more comments.
Some people have said that CSLA is verbose compared to things like LINQ to SQL and so on. But here we're comparing apples to oranges. LINQ to SQL is an ORM. It offers some things that CSLA does not, and CSLA offers some things L2S does not, like integrated validation and n-tier persistence through the various remote data portals. In fact, I'd say that last thing, n-tier persistence, trumps them all for me. If I want to use Entity Framework or LINQ to SQL over the net, I have to put something like WCF in between, and that multiplies the work and complexity enormously, to the point where I think it is much more verbose than CSLA. (Now, I'm a fan of WCF, REST and SOA, but use it where you really need it, such as when you want to expose a service to third parties. For most line-of-business apps, it isn't really needed, and CSLA is a better choice.) In fact, with the latest version of CSLA, Rocky provides a
WCFDataPortal, which I've used. It works great.I'm a fan of SOLID, TDD, and other modern software development principles, and use them wherever practical. But I think the benefits of CSLA outweigh some of the objections of those orthodoxies, and in any case I've managed to make CSLA work quite well (and easily) with TDD, so that's not an issue.
我是一个 PHP 人。 当我们开始使用 PHP 构建相对较大规模的应用程序时，我开始研究大量应用程序框架和 ORM，主要是在 PHP 领域，然后是 Java 和 .NET。 我之所以关注 Java 和 .NET 框架，是为了不盲目使用任何 PHP 框架，而是首先尝试了解到底发生了什么，以及存在什么样的企业级架构。
因为我没有在现实世界的应用程序中使用过 CSLA，所以我无法评论它的优缺点，但我可以说的是，Lhotka 是软件架构领域中罕见的思想家（我并不是说只是专家）之一。 虽然领域驱动设计这个名字是由 Eric Evans 创造的——顺便说一句，他的书也很棒，我谦虚地建议阅读它——Lhotka 多年来一直在应用领域驱动设计。 话虽如此，无论您如何看待他的框架，都可以从他在该领域的深刻思想中受益。
您可以在 dotnetrocks.com/archives.aspx 上找到他的演讲，也可以在 dnrtv.com/archives.aspx 上找到他的视频（搜索 Lhotka）。
@拜伦
您喜欢的另外两本书是什么？
I'm a PHP guy. When we started building comparatively large scale applications with PHP, I started researching on lots of application frameworks and ORMs essentially in PHP world, then in Java and .NET. The reason I also looked at Java and .NET frameworks was not to blindly use any PHP framework, but first try to understand what is really going on, and what kind of enterprise level architectures are there.
Because I haven't used CSLA in a real world application, I can't comment on its pros and cons, but what i can say is Lhotka is one the rare thinkers -I'm not saying just expert- in Software Architecture field. Although the name Domain Driven Design is coined by Eric Evans -by the way his book is also great and i humbly advise to read it- Lhotka was applying domain driven design for years. Having said that, whatever you think about his framework, benefit from his profound ideas in the field.
You can find his talks on dotnetrocks.com/archives.aspx and videos from dnrtv.com/archives.aspx (search for Lhotka).
@Byron
What are the other two books you liked?
我是 CSLA 的新手，但我了解这些概念，而且我已经知道它不是一个 ORM 工具，所以别再打败那些该死的鼓手了。 CSLA 有一些功能我很喜欢，但使用它们感觉有点像幕后有一位魔术师。 我想如果你不介意不知道它是如何工作的，那么你可以使用这些对象并且它们工作得很好。
对于初学者来说，学习曲线很大，我认为 5-15 分钟会受益匪浅。 像 Microsoft 那样的用于学习基础知识的视频。 或者发布一本包含代码的姊妹书怎么样，而不是发布代码并花几个月的时间来发布这本书？ 只是说 Lohtka 先生......我们在这本书之前就开始构建我们的东西，我一直在挣扎。 但就像我说的，我对此很陌生。
我们使用了 CSLA。 我们让我们的对象适合他们的模具，然后使用框架提供的 10%。 对象级撤消？ 没用过。 NT层灵活性？ 没用过。 我们最终编写了足够的业务规则代码，我认为我们从 CSLA 中得到的唯一好处就是复杂性。 一些了解该框架的“老顽固”开发人员将其用作锤子，因为他们有一颗钉子需要敲击。 CSLA 就在他们的手中，我猜该框架的许多支持者也从这个角度看待事物。
我想我们经验丰富的开发人员很高兴，因为这对他们来说都是有意义的。 我想，如果您的组织没有新手程序员，并且你们对编写具有良好格式模式的高效且简单的 POCO 对象感到厌倦，那么就去做吧。 使用 CSLA。
I'm new to CSLA but I understand the concepts and I already understand that it's not an ORM tool so quit beating that damn drum folks. There are features of CSLA I like but using them feels a bit like there is a magician behind the curtain. I guess if you don't mind not knowing about how it works then you can use the objects and they work fine.
There is a large learning curve for beginners and I think it would benefit greatly by having 5-15 min. videos like Microsoft has for learning the fundamentals. Or how about releasing a companion book with the code instead of getting the code released and taking months to get the book out? Just sayin Mr Lohtka... We started building our stuff before the book and I struggled the whole time. But like I said, I'm new to it.
We used CSLA. We made our objects fit their mold then used 10% of what the framework offered. Object level undo? Didn't use it. NTier flexibility? Didn't use it. We ended up writing enough business rule code that I thought the only thing we were getting out of CSLA was complexity. Some "long in the tooth" developers that know the framework used it as their hammer because they had a nail that needed hitting. CSLA was in their belt and my guess is a lot of proponents of the framework see things from that perspective too.
I guess our seasoned developers are happy because it all makes sense to them. I guess if your organization doesn't have newbie programmers and you guys get bored by writing efficient and simple POCO objects with well formed patterns, then go for it. Use CSLA.
我们开始使用 CSLA 是因为我们认为它会对我们的模型层有所帮助。 有点矫枉过正，我们现在使用的主要是 SmartDate 类，只是因为我们已经链接到该库。
我们认为验证接口确实可以帮助我们执行业务规则，但它不能很好地与 WCF 和序列化配合使用（我们仍然停留在版本 2.0.3.0 上，因此情况可能已经发生了变化）。
We started using CSLA because we thought it would help with our model layer. Was sort of overkill and mostly all we use now is the SmartDate class, just because we're already linked to the library.
We thought the validation interface would really help us enforce business rules but it didn't work well with WCF and serialization (we're still stuck on version 2.0.3.0, so things might have changed).
我从 vb5 开始就一直在使用 CSLA，当时它更多的是模式的集合，而不是一个框架。 随着 .NET 的引入，CSLA 变成了一个成熟的框架，但学习曲线却很艰巨。 然而，CSLA 解决了所有业务开发人员倾向于在某个时候自己编写的许多内容（取决于项目范围）：验证逻辑、身份验证逻辑、撤消功能、脏逻辑等。所有这些内容都可以从 CSLA 中免费获得。盒子在一个漂亮的框架中。
正如其他人所说，作为一个框架，它迫使开发人员以类似的方式编写业务逻辑。 它还迫使您为业务逻辑提供一定程度的抽象，这样不使用 MVC、MVP、MVVM 等 UI 框架就变得不那么重要了。
事实上，我认为，今天（在微软世界）这么多 UI 模式如此大肆宣传的原因是人们长期以来一直在做一些令人难以置信的错误的事情（即，在 UI 中使用 DataGrid，洒水你的业务逻辑无处不在。 从一开始就正确设计您的中间层（业务逻辑），您可以在任何 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 中使用这种方法。 我采用的方法是使用类和序列图对中间层（业务对象）进行建模，最常见的是允许用例、屏幕和/或流程设计来指示。 也许有点老派，但 UML 在我的设计和开发工作中一直为我提供了很好的帮助。 我成功地设计和开发了非常大且可扩展的应用程序，至今仍在使用。 在 WCF RIA 成熟之前，我将继续使用 CSLA..
** 以及一些解决方法
I've been using CSLA since vb5, when it was more of a collection of patterns than it was a framework. With the introduction of.NET, CSLA turned into a full-blown framework, that came with a hefty learning curve. However, the CSLA addresses many things that all business developers tend to write themselves at some point (depending on project scope): validation logic, authentication logic, undo functionality, dirty logic, etc. All of these things you get for free out of the box in one nice framework.
As others have stated, being a framework, it forces developers to write business logic in a similar fashion. It also forces you to provide a level of abstraction for your business logic, so that not using a UI framework such as MVC, MVP, MVVM becomes not so important.
In fact, I would argue that the reason why so many of these UI patterns are so hyped up today (in the Microsoft world) is that people have been doing stuff incredibly wrong for so long (ie., using DataGrids in your UI, sprinkling your business logic everywhere. tisk tisk). Design your middle tier (business logic) correctly from the start, you can reuse your middle tier in ANY UI. Win Form, ASP.NET/MVC, WCF Service, WPF, Silverlight**, Windows Service, ....
But aside from these, the huge payoff for me has been it's built-in ability to scale. The CSLA uses a proxy pattern that is configurable via your config file. This allows your business objects to make remote calls from server to server, without having to write one lick of code. Adding more users to your system? No problem, deploy your CSLA business objects to a new application server, make a config file entry change, and BAM!! Instant scalability needs met.
Compare this to using DTO's, storing your business logic on the client (whatever client that may be), and having to write each of your own CRUD methods as service methods. YIKES!!! Not saying this is a bad approach, but I wouldn't want to do it. Not when there's a framework out there to essentially do it for me.
I'm going to reiterate what other folks have said in that CSLA is NOT an ORM. CSLA forces you to supply your business objects with data. They do not care where you get your data. You can use an ORM to supply your business objects with data. You can also use raw ADO.NET, other services (RESTFUl, SOAP), excel spreadsheets, I can keep going here.
As for your support for TDD, I have never tried using that approach with CSLA either. I have taken the approach where I model my middle tier (ala business objects) using class and sequence diagrams, most often allowing use case, screen and/or process design to dictate. Perhaps a bit old school, but UML has always served me very well in my design and development efforts. I've successfully designed and developed very large and scalable applications still being used today. And until WCF RIA matures, I'll be continuing to use CSLA..
** with some work arounds
我们使用 CSLA 已有五年多了，我们认为它非常适合构建业务应用程序。 与代码生成相结合，您可以在相对较短的时间内创建业务对象，并将精力集中在应用程序的核心上。
We've been using CSLA now for over five years, and we think it works great for constructing business applications. Coupled with code generation you can create business objects in a relative short amount of time and focus your effort on the meat of the application.
我们广泛使用 CSLA。 有几个好处； 首先，我相信每个业务开发人员都应该阅读 Rocky Lhotka 的有关业务对象编程的书。 我个人认为它是我有史以来最好的三本编程书籍之一。 CSLA 是一个基于本书的框架，使用它可以让您的项目访问非常高级的功能，例如 n 级撤消、验证规则和可扩展性架构，同时为您提供详细信息。 请注意，我说的是“提供”而不是“隐藏”。 我发现 CSLA 最好的部分是让您了解所有这些内容是如何实现到源代码的，而不需要您自己重现它们。 您可以根据需要选择使用任意数量的功能，但我发现，通过忠实于框架的设计模式，它确实可以让您摆脱麻烦。
——拜伦
We use CSLA extensively. There are several benefits; first, I believe that every line of business developer should read Rocky Lhotka's book on Business Objects programming. I've personally found it to be in my top 3 best programming books ever. CSLA is a framework based on this book and using it gives your project access to very high level functionality like n-level undo, validation rules and scalability architecture while providing the details for you. Notice I said "providing" and not "hiding". I've found that the best part of CSLA is that is makes you understand how all of these things are implemented down to the source code without making you reproduce them yourself. You can choose to use as many or few features as you need but I've found that by staying true to the design patterns of the framework, it really keeps you out of trouble.
--Byron
我们公司在一些项目中实施了 CSLA，而一些遗留项目仍然采用 CSLA。 其他项目放弃了它，因为 CSLA 违反了一条简单明了的 OOP 规则：单一职责原则。
CSLA 对象是自我维持的，例如，它们检索自己的数据、管理自己的行为、拯救自己。 不幸的是，这意味着您的平均 CSLA 对象至少具有三个职责 - 表示域模型、包含业务规则以及包含数据访问定义（不是 DAL，或数据访问实现，如我之前所述/暗示的）时间。
Our company practised CSLA in some of its projects and some of the legacy projects remain to be CSLA. Other projects moved away from it because CSLA violated a plain and simple OOP rule: Single Responsibility Principle.
CSLA objects are self-sustaining, e.g. they retrieve their own data, they manage their own behavior, they save themselves. Unfortunately this meant that your average CSLA object has at least three responsibilities -- representing the domain model, containing business rules, and containing data access definition (not the DAL, or data access implementation, as I previously stated/implied) all at the same time.
不要只考虑 CSLA 的列表，但在使用它之前，研究一下它的好处并确保它们确实适用。 您的团队能够正确/一致地实施它吗？ 需要远程和门户舞蹈吗？
我认为除了所有的理论思考之外，这都是关于遵循基本的经过验证的模式的干净/可维护/可扩展/可测试的代码。
我计算了从 CSLA 转换的项目的特定域中所需的代码行数。 在所有不同的 CSLA 对象（只读+可编辑+根+列表组合）及其存储过程之间，大约需要 1700 行，而 Linq2SQL + Repository 实现则需要 180 行。 Linq2SQL 版本主要由生成的类组成，您的团队无需阅读书籍即可理解这些类。 是的，我使用 CodeSmith 生成了 CSLA 部分，但我现在相信具有单一责任位的 DRY 代码，并且 CSLA 实现现在在我看来就像昨天的英雄。
作为替代方案，我建议研究 Linq2Sql/Entity Framework/NHibernate 与 Repository 和 UnitOfWork 模式的结合。 看看 http://www.codeplex.com/backgroundmotion
干杯！
Not to take CSLA of the list, but before using it, research the benefits and make sure they really apply. Will your team be able to correctly/consistently implement it? Remoting and portal dance needed?
I think beyond all the theoretical ponder, it is all about clean/maintainable/extendable/testable code following basic proven patterns.
I counted lines of code needed in a specific domain of a project converted from CSLA. Between all the different CSLA objects(readonly+editable+root+list combinations) and their stored procs it took about 1700 lines, versus a Linq2SQL + Repository implementation that took 180 lines. The Linq2SQL version consisted mostly of generated classes that your team doesn’t need to consume book to understand. And yes, I used CodeSmith to generate the CSLA parts, but I now believe in DRY code with single responsibility bits, and the CSLA implementation now looks to me like yesterday’s hero.
As an alternative I would like to suggest looking into Linq2Sql/Entity Framework/NHibernate combined with Repository and UnitOfWork patterns. Have a look at http://www.codeplex.com/backgroundmotion
Cheers!
是的，我（嗯，我们）广泛使用它来建模我们的业务流程逻辑，该逻辑主要是 Windows 表单应用程序中的数据绑定表单。 该应用程序是一个交易系统。 CSLA 被设计为位于 UI 下方的该层。
如果您考虑标准的复杂业务线应用程序，您可能有一个包含许多字段的表单，这些字段的许多规则（包括跨字段验证规则），您可以调用模式对话框来编辑某些子对象，您可以希望能够取消此类对话框并恢复到以前的状态。 CSLA 支持这一点。
它的缺点是它有一点学习曲线。
要记住的关键一点是使用 CSLA 来模拟用户如何与某些应用程序上的表单交互。 对我来说最有效的方法是在构建 CSLA 对象之前设计 UI 并了解它的流程、行为和验证规则。 不要让 CSLA 对象驱动 UI 设计。
我们还发现能够使用 CSLA 业务对象服务器端来验证从客户端发送的对象非常有用。
我们还内置了针对 Web 服务执行异步验证的机制（即根据主服务器检查交易对手的信用限额范围）。
CSLA 在 UI、业务逻辑和持久性之间强制实施严格分离，我们针对它们编写了大量单元测试。 它可能不是严格的 TDD，因为您是通过 UI 设计来驱动它的，但这并不意味着它不可测试。
唯一真正的替代方案是创建您自己的模型 \ 业务对象，但很快您最终就会实现 CSLA 提供的开箱即用的功能（INotifyPropertyChanged、IDataErrorInfo、PushState、PopState 等）
Yes, I (um, we) used it extensively to model our business process logic that was primarily databound forms in a windows forms application. The application was a trading system. CSLA is designed to be at that layer just below the UI.
If you think about your standard complex line-of-business application you may have a form with many fields, many rules for those fields (including cross-field validation rules), you may invoke a modal dialog to edit some child object, you may want to be able to be able to cancel such dialogs and revert back to a previous state. CSLA supports this.
It's cons are that it has a bit of a learning curve.
The key thing to remember is to use CSLA to model how a user interacts with forms on some application. The most efficient way for me was to design the UI and understand it's flows, behaviour and validation rules before building the CSLA objects. Don't have your CSLA objects drive UI design.
We also found it very useful to be able to use CSLA business objects server side to validate objects sent from clients.
We also had built in mechanisms to perform validation asynchronously against web service (i.e. checking the credit limit range of a counterparty against a master).
CSLA enforces a strong seperation between your UI, BusinessLogic and Persistance and we wrote a load of unit tests against them. It may not be strictly TDD because you are driving it from UI design, that doesn't mean it isn't testable.
The only real alternative is creating your own model \ business objects, but pretty soon you end up implementing features that CSLA offers out of the box (INotifyPropertyChanged, IDataErrorInfo, PushState, PopState etc.)
在具体回答你的问题之前，我想先说几点想法。 CSLA 适合您的项目吗？ 这取决于。 我个人认为 CSLA 适用于基于桌面的应用程序，这些应用程序不将单元测试视为高优先级。 如果您想轻松扩展到 n 层应用程序，CSLA 非常有用。 CSLA 往往会受到一些批评，因为它不允许纯粹的单元测试。 这是事实，但就像技术中的任何事情一样，我相信没有一种正确的方法。 单元测试可能不是您针对特定项目进行的事情。 对一个团队和一个项目有效的方法可能不适用于另一个团队或其他项目。
关于 CSLA 也存在许多误解。 它不是一个 ORM。 它不是 NHibernate 的竞争对手（事实上，使用 CLSA Business Objects 和 NHibernate，因为数据访问非常适合）。 它正式化了移动对象的概念。
1. 有多少人在使用 CSLA？
根据 CSLA 论坛，我想说有相当多的基于 CSLA 的项目那里。 老实说，我不知道有多少人真正在使用它。 我过去在两个项目中使用过它。
2. 有什么优点和缺点？
虽然很难用简短的列表来概括，但以下是我想到的一些优点/缺点。
优点：
加速。 CSLA 书籍和样本
应用程序是加快速度的重要资源。
重新编译是必要的）
引入后，影响微乎其微
CSLA 代码。
缺点：
3. 读完这篇文章后，CSLA 真的不适合 TDD 吗？
我还没有找到使用 CSLA 进行 TDD 的有效方法。 也就是说，我确信有很多比我更聪明的人可能已经尝试过并取得了更大的成功。
4. 我有什么选择？
领域驱动设计目前正受到大力推动（这是理所当然的——它对于某些应用程序来说非常棒）。 由于 LINQ（以及 LINQ to SQL、Entity Framework 等）的引入，还开发了许多有趣的模式。 Fowlers 的书 PoEAA 详细介绍了许多可能适合您的应用程序的模式。 请注意，某些模式是相互竞争的（即 Active Record 和 Repository），因此旨在用于特定场景。 虽然 CSLA 并不完全匹配该书中描述的任何模式，但它与 Active Record 最相似（尽管我觉得声称与该模式完全匹配是短视的）。
5. 如果您已停止使用它或决定不使用它，原因是什么？
对于我的上一个项目，我没有完全推荐 CSLA，因为我认为应用程序的范围对于 CSLA 提供的好处来说太大了。
我不会在网络项目上使用 CSLA。 我认为还有其他技术更适合在该环境中构建应用程序。
总之，虽然 CSLA 绝非万能药，但它适用于某些场景。
希望这可以帮助！
Before I specifically answer your question, I'd like to put a few thoughts down. Is CSLA right for your project? It depends. I would personally consider CSLA for desktop based applications that does not value unit testing as a high priority. CSLA is great if you want to easily scale to an n-tier application. CSLA tends to get some flack because it does not allow pure unit testing. This is true, however like anything in technology, I believe that there is No One True Way. Unit testing may not be something you are undertaking for a specific project. What works for one team and one project may not work for another team or other project.
There are also many misconceptions in regards to CSLA. It is not an ORM. it is not a competitor to NHibernate (in fact using CLSA Business Objects & NHibernate as data access fit really well together). It formalises the concept of a Mobile Object.
1. How many people are using CSLA?
Based on the CSLA Forums, I would say there are quite a number of CSLA based projects out there. Honestly though, I have no idea how many people are actually using it. I have used it in the past on two projects.
2. What are the pros and cons?
While it is difficult to summarise in a short list, here is some of the pro/con's that come to mind.
Pros:
to speed. The CSLA book and sample
app are great resources to get up to speed.
recompile is necessary)
introduced, it had minimal impact on
CSLA code.
Cons:
3. After reading this does CSLA really not fit in with TDD?
I haven't found an effective way to do TDD with CSLA. That said, I am sure there are many smarter people out there than me that may have tried this with greater success.
4. What are my alternatives?
Domain-Driven-Design is getting big push at the moment (and rightfully so - it's fantastic for some applications). There are also a number of interesting patterns developing from the introduction of LINQ (and LINQ to SQL, Entity Framework, etc). Fowlers book PoEAA, details many patterns that may be suitable for your application. Note that some patterns are competing (i.e. Active Record and Repository), and thus are meant to be used for specific scenarios. While CSLA doesn't exactly match any of the patterns described in that book, it most closely resembles Active Record (although I feel it is short-sighted to claim an exact match for this pattern).
5. If you have stopped using it or decided against why?
I didn't fully recommend CSLA for my last project, because I believe the scope of the application is too large for the benefits CSLA provides.
I would not use CSLA on a web project. I feel there are other technologies better suited to building applications in that environment.
In summary, while CSLA is anything but a silver bullet, it is appropriate for some scenarios.
Hope this helps!
我在一个项目中使用了 CSLA，它效果很好，让事情变得更加简单和整洁。
我们知道有一个共同的标准来工作，而不是让您的团队以自己不同的个人风格编写业务对象。
//安迪
I have used CSLA for one project and it worked great and make things much simpler and neater.
Instead of having your team writing business objects in their own different personal style, we know have a common standard to work against.
//andy
几年前我就有过这方面的经验。 它是一个出色的架构，但非常复杂，难以理解或更改，并且它解决了我们大多数开发基于 Web 应用程序的人不一定遇到的问题。 它更多地是为基于 Windows 的应用程序和处理多级撤消而开发的，特别强调事务逻辑。 您可能会听到人们说，由于 Web 应用程序是页面级别的请求-响应，所以这是不合适的，但对于 AJAX 风格的 Web 应用程序来说，这个论点可能站不住脚。
它有一个非常深入的对象模型，你可能需要一段时间才能真正理解它。 当然，几年之内可能会发生很多变化。 我有兴趣听到其他最近的意见。
综合考虑，它不会是我建筑的第一选择。
I had experience with it several years ago. It is a brilliant architecture, but very complex, difficult to understand or change, and it's solving a problem that most of us developing web based applications don't necessarily have. It was developed more for windows based applications and handling multi-level undo, with a heavy emphasis on transactional logic. You will probably hear people say that since web applications are request-response at the page level, it is inappropriate, but with AJAX-style web apps maybe this argument doesn't hold so much water.
It has a very deep object model, and it can take a while to really wrap your brain around it. Of course, a lot can change in a few years. I would be interested to hear other recent opinions.
All things considered, it would not be my first choice of architecture.
为了捍卫 CSLA，尽管我确实同意许多评论，特别是单元测试评论……
我的公司广泛将其用于 Windows 窗体数据输入应用程序，并取得了很大的成功。
总的来说，我想说，它所带来的任何问题都远远超过了它带来的好处。
更新：除此之外，我们仍在将它用于我们的 Windows 窗体应用程序，但将其用于其他应用程序（例如网站）的实验表明，当您不需要它的太多功能时，它可能会很麻烦，我们现在正在调查针对这些场景的更轻重量的选择。
In defence of the CSLA, although I do agree with many of the comments that have been made particularly the unit testing one...
My company used it extensively for a Windows Forms data entry application, with a high degree of success.
On the whole I would say that any issues that it caused were more than outwayed by the benefits.
UPDATE: Further to this we are still using it for our windows forms app but experiments with using it for other applications such as web sites have shown that it is perhaps to cumbersome when you don't need much of its functionality and we are now investigating lighter weight options for these scenarios.
我加入了一个强制执行 CSLA 的团队。 我们不使用远程数据门户，这是我同意使用该框架的唯一原因。 我从来没有接受过 CSLA 的想法，所以也许这就是为什么我对它只有一些问题，抱歉。
有几个问题：
我不需要在我的代码和 .NET 框架之间设置路障，这就是我对这个框架的感觉。 我对列表对象的选择有限，而我只能忽略 .NET 框架中丰富的列表对象。
这是完全荒谬的，我们有这些只读列表，然后是非只读列表。 因此，如果我必须向列表中添加一个项目，我就必须重新创建整个列表......你是认真的吗？
然后 csla 想要管理我的对象状态，这很好，但没有真正暴露任何内容。 有时我想手动更改对象状态，而不是再次获取它，这似乎是 csla 希望我做的。 我基本上最终创建了许多属性来公开 csla 认为我不应该直接访问的选项。
为什么我不能实例化一个对象？ 我们最终创建了静态方法来实例化一个对象并将其传回......你在开玩笑吗？
检查框架源代码，在我看来，反射代码看起来很重。
使用 csla 的原因：
您的开发人员经验不足，无法掌握模式的概念，那么 csla 几乎会让每个人都达成共识。
I joined a team where CSLA is mandatory. We don't use the remote data portal which is the only reason I could agree for usage of this framework. I never bought into the idea of CSLA so maybe that's why I have nothing but issues with it, sorry.
A couple of the issues:
I don't need a road block between my code and the .NET framework which is what this framework felt like to me. I had a limited option of list objects, while I just had to ignore the rich list objects in the .NET framework.
Ii is totally ridiculous that we had these read-only lists and then non read-only lists. So if I had to add an item to the list I had to recreate the entire list...are you serious?
Then csla wants to manage my object state which is fine but nothing is really exposed. Sometimes I want to change an object state manually instead of fetching it again which seems like what csla wants me to do. I basically end up creating many properties to expose options csla didn't think I should have direct access to.
Why can't I just instantiate an object? We end up creating static methods which instantiates an object and passes it back...are you kidding me?
Check the framework source code and it looks to heavy on the reflection code to me.
Reasons to use csla:
your developers are not seasoned and can't grasp the concept of patterns then csla will pretty much have everyone on the same page.