有没有人有任何CSLA的现实世界的经验？
我公司的主要Web应用程序正在呼吁一个漂亮的图书馆，使其在某种程度上可维护和可扩展，我的一个同事build议CSLA。 所以我买了书，但是：
程序员不再读书了
我想衡量SOFlow社区对此的看法。
所以这是我的问题：
- 人们如何使用CSLA？
- 优缺点都有什么？
- CSLA是否真的不适合TDD？
- 我的替代品是什么？
- 如果你已经停止使用它或决定反对为什么？
在我具体回答你的问题之前，我想先说一点。 CSLA是否适合您的项目？ 这取决于。 我个人认为CSLA是基于桌面的应用程序，并不重视unit testing的重要性。 如果您想要轻松扩展到n层应用程序，CSLA非常棒。 CSLA往往得到一些flack，因为它不允许纯粹的unit testing。 这是事实，不pipe科技如何，我相信没有一条真正的道路 。 unit testing可能不是您正在为特定项目进行的事情。 对一个团队和一个项目有效的方法可能不适用于另一个团队或其他项目。
关于CSLA也有很多误解。 这不是一个ORM。 它不是NHibernate的竞争对手（实际上使用CLSA Business Objects＆NHibernate作为数据访问非常适合）。 它forms化了移动对象的概念。
1.有多less人在使用CSLA？
基于CSLA论坛 ，我会说在那里有很多CSLA的项目。 老实说，我不知道有多less人在使用它。 我曾经在两个项目中使用过。
2.什么是利弊？
虽然在一个简短的列表中难以概括，但是这里有一些关于pro / con的内容。
优点：
- 让新开发人员加快速度很容易。 CSLA的书籍和示例应用程序是很好的资源，以加快速度。
- validation框架是真正的世界级的，并已被许多其他非CSLA项目和技术“借用”。
- 您的业务对象中的N级撤消
- configuration行更改为n层可伸缩性（注意：甚至不需要重新编译）
- 关键技术是从“真实”的代码中抽象出来的。 当WCF被引入时，它对CSLA代码的影响很小。
- 可以在Windows和Web项目之间共享您的业务对象。
- CSLA促进行为规范化，而不是数据规范化（数据库正常化）。
缺点：
- unit testing困难
- 缺乏关注的分离（通常你的业务对象里面有数据访问代码）。
- 由于CSLA促进了行为的规范化，而不是数据的规范化，这可能导致业务对象被命名为相似，但具有不同的目的。 这可能会导致一些混淆和感觉，就像你不适当地重复使用对象。 也就是说，一旦采取了生理学上的跳跃，这不仅仅是有意义的 – 把物体构造成“老”的方式似乎是不合适的。
- 以这种方式构build应用程序并不“stream行”。 您可能很难find对这项技术充满热情的开发人员。
3.读完这个后，CSLA是否真的不适合TDD？
我还没有find一个有效的方法来与CSLA进行TDD。 也就是说，我确信有比我更聪明的人，可能会试图取得更大的成功。
4.我的替代品是什么？
领域驱动devise正在变得越来越重要（对于某些应用程序而言，这是非常棒的）。 从LINQ的引入（以及LINQ到SQL，entity framework等）也有许多有趣的模式。 福勒书PoEAA ，详细可能适合您的应用程序的许多模式。 请注意，一些模式是竞争（即活动logging和存储库），因此是用于特定的情况。 虽然CSLA并不完全符合该书中所描述的任何模式，但它与Active Record非常相似（尽pipe我认为要求这种模式完全匹配是短视的）。
5.如果你已经停止使用它或为什么决定？
我没有完全推荐CSLA作为我的最后一个项目，因为我相信这个应用程序的范围对于CSLA提供的好处来说太大了。
我不会在网站上使用CSLA。 我觉得还有其他更适合在该环境中构build应用程序的技术。
总之，虽然CSLA不过是一颗银弹 ，但对于一些场景来说是合适的。
希望这可以帮助！
看完所有答案后，我注意到有不less人对CSLA有一些误解。
首先， CSLA不是一个ORM 。 我怎么能这么说呢？ 因为Rockford Lhotka已经多次在.NET Rocks和Hanselminutes播客中对自己进行了访谈。 看看洛奇接受采访的任何一集，他会毫不含糊地陈述。 我认为这是人们理解的最关键的事实，因为几乎所有关于CSLA的错误观念都是由于认为它是一个ORM或试图将其作为一个整体来使用。
正如Brad Leach在他的回答中提到的那样，CSLA反对模型行为，尽pipe说他们模拟数据的行为可能更准确，因为数据是他们不可或缺的。 CSLA不是一个ORM，因为它完全不知道你如何与你的数据存储进行交谈。 你应该使用CSLA的某种数据访问层，甚至可能是一个ORM。 （我这样做，我现在使用entity framework，它工作得很好。）
现在，到unit testing。 我从来没有任何困难的unit testing我的CSLA对象，因为我没有把我的数据访问代码直接到我的业务对象。 相反，我使用存储库模式的一些变化。 版本库被CSLA使用，而不是相反。 通过交换我的unit testing和使用本地数据门户网站BOOM！ 这很简单。 （一旦entity framework允许使用POCO，这将更加清洁。）
所有这些都来自于认识到CSLA不是一个ORM。 它可能会消耗一个ORM，但它本身不是一个。
干杯。
UPDATE
我想我会再提出一些意见。
有些人说CSLA比LINQ to SQL等东西是冗长的。 但是我们在这里比较苹果和橘子。 LINQ to SQL是一个ORM。 它提供了一些CSLA不能提供的东西，而CSLA提供了L2S不提供的一些东西，比如通过各种远程数据门户进行集成validation和n层持久化。 事实上，我会说，最后一件事情是，不断的坚持，胜过我的一切。 如果我想通过networking使用entity framework或者LINQ to SQL，我必须在WCF之间插入一些东西，这会使工作和复杂性大大增加，到了我认为它比CSLA更加冗长的地步。 （现在，我是WCF，REST和SOA的粉丝，但是在真正需要它的地方使用它，比如当你想向第三方公开服务的时候，对于大多数业务线应用程序来说，真的很需要，CSLA是更好的select。）事实上，在最新版本的CSLA中，Rocky提供了一个我用过的WCFDataPortal 。 它工作很好。
我是SOLID ，TDD和其他现代软件开发原则的粉丝，并在实际中使用它们。 但我认为CSLA的好处超过了一些正统观点的反对意见，无论如何，我已经设法使CSLA能够很好地（很容易地）用TDD工作，所以这不是问题。
是的，我（嗯，我们）广泛地使用它来模拟我们的业务stream程逻辑，主要是在Windows窗体应用程序中形成数据绑定表单。 该应用程序是一个交易系统。 CSLA被devise为位于用户界面下的那一层。
如果您考虑标准复杂的业务线应用程序，则可能会有一个包含多个字段的表单，这些字段的许多规则（包括交叉字段validation规则），您可以调用一个模式对话框来编辑某个子对象，您可以希望能够取消这样的对话并恢复到以前的状态。 CSLA支持这一点。
它的缺点是它有一点学习曲线。
要记住的关键是使用CSLA来模拟用户如何在某些应用程序上与表单进行交互。 对我来说最有效的方法是在构buildCSLA对象之前deviseUI并理解它的stream程，行为和validation规则。 没有你的CSLA对象驱动UIdevise。
我们还发现能够使用CSLA业务对象服务器端来validation从客户端发送的对象是非常有用的。
我们还build立了一些机制，以asynchronous的方式对Web服务进行validation（即检查对方的信用额度范围）。
CSLA在您的用户界面，BusinessLogic和Persistance之间执行强有力的分离，我们为它们编写了一系列的unit testing。 它可能不是严格的TDD，因为你是从UIdevise驱动它，这并不意味着它是不可testing的。
唯一真正的select是创build自己的模型\业务对象，但很快你会实现CSLA提供的开箱即用function（INotifyPropertyChanged，IDataErrorInfo，PushState，PopState等）
我几年前就有过这方面的经验。 这是一个很好的架构，但非常复杂，很难理解或改变，它正在解决一个问题，即我们大多数开发基于Web的应用程序并不一定。 它被开发更多的基于Windows的应用程序和处理多级撤消，重点强调事务逻辑。 您可能会听到有人说，因为Web应用程序是在页面级别的请求响应，这是不合适的，但是对于AJAX风格的Web应用程序来说，这个说法可能并不是那么有用。
它有一个非常深刻的对象模型，可能需要一段时间才能真正包围你的大脑。 当然，很多年后可以改变。 我会有兴趣听到最近的其他意见。
所有的事情考虑，这不会是我的首选build筑。
我曾经用CSLA做过一个项目，它工作的很好，让事情变得简单和整洁。
与其让团队用自己不同的个人风格写业务对象，我们知道有一个共同的标准来对付。
//安迪
为了保卫CSLA，尽pipe我同意许多人的意见，特别是unit testing。
我公司广泛用于Windows Forms数据录入应用程序，取得了很高的成功率。
- 它提供了开箱即用的function，我们没有时间或专业知识来自己写。
- 它标准化了我们所有的业务对象，使维护变得简单，减less了我们新开发人员的学习曲线。
总的来说，我认为它造成的任何问题都远不止于此。
更新：除此之外，我们仍然使用它作为我们的Windows窗体应用程序，但是将其用于其他应用程序（如Web站点）的实验表明，当您不需要太多function时可能会很麻烦，现在我们正在调查这些场景的重量更轻。
我join了CSLA强制性的团队。 我们不使用远程数据门户，这是我可以同意使用这个框架的唯一原因。 我从来没有买过CSLA的想法，所以也许这就是为什么我什么也没有问题，对不起。
几个问题：
我不需要在我的代码和.NET框架之间有一个障碍，这个框架对我来说就是这样。 我有一个有限的列表对象的选项，而我只是不得不忽略在.NET框架中丰富的列表对象。
我很荒唐，我们有这些只读列表，然后是非只读列表。 所以，如果我不得不添加一个项目的列表，我不得不重新创build整个列表…你认真吗？
然后csla想pipe理我的对象状态是好的，但没有真正暴露。 有时我想手动更改对象状态，而不是再次获取它，这似乎是csla希望我做的。 我基本上最终创build了很多属性来暴露选项csla不认为我应该直接访问。
为什么我不能实例化一个对象？ 我们最终创build了一个静态方法来实例化一个对象并将其传回…你在开玩笑吗？
检查框架的源代码，它看起来沉重的reflection代码给我。
使用csla的理由：
- 直的.net框架对你来说太强大了。
-
你的开发人员没有经验，不能掌握模式的概念，那么CSA将几乎每个人都在同一页面上。
- 我不需要我的代码和.NET框架之间的路障…我坚持这些列表对象。
我们开始使用CSLA，因为我们认为这将有助于我们的模型层。 有点矫枉过正，现在大部分我们使用的都是SmartDate类，只是因为我们已经链接到了图书馆。
我们认为validation接口确实可以帮助我们实施业务规则，但是对于WCF和序列化（我们仍然停留在版本2.0.3.0，所以事情可能已经改变了），它不能很好地工作。
不要拿CSLA的名单，但在使用之前，研究的好处，并确保他们真正适用。 你的团队能够正确/一致地实施它吗？ 远程和门户舞蹈需要？
我认为，除了所有的理论思考之外，所有关于清洁/可维护/可扩展/可testing的代码都遵循基本的经过validation的模式。
我计算了从CSLA转换的项目的特定领域所需的代码行数。 在所有不同的CSLA对象（只读+可编辑+根+列表组合）和它们存储的特效之间，大约需要1700行，而Linq2SQL +实现需要180行。 Linq2SQL版本主要由生成的类组成，您的团队不需要使用本书来理解。 是的，我使用CodeSmith来生成CSLA部分，但是现在我相信DRY代码具有单一的责任位，CSLA的实现现在看起来像昨天的英雄。
作为另一种select，我想build议查看Linq2Sql /entity framework/ NHibernate结合存储库和UnitOfWork模式。 看看http://www.codeplex.com/backgroundmotion
干杯!
我们公司在部分项目中实施了CSLA，一些遗留项目仍然是CSLA。 由于CSLA违反了一个简单而简单的OOP规则：单一责任原则，其他项目已经离开了它。
CSLA的对象是自我维持的，例如，他们检索自己的数据，pipe理自己的行为，自我保存。 不幸的是，这意味着您的平均CSLA对象至less有三个职责 – 代表领域模型，包含业务规则，并包含数据访问定义（而不是DAL或数据访问实现，如前所述/暗示的）时间。
我们已经使用CSLA超过五年了，我们认为它对构build业务应用程序非常有用。 再加上代码生成，您可以在相对较短的时间内创build业务对象，并将精力集中在应用程序的肉中。
我们广泛使用CSLA。 有几个好处; 首先，我相信业务开发者的每一行都应该阅读Rocky Lhotka关于Business Objects编程的书籍。 我个人发现它是我的前三名最好的编程书籍。 CSLA是一本基于本书的框架，使用它可以让您的项目访问非常高级的function，如n级撤消，validation规则和可扩展性架构，同时为您提供详细信息。 通知我说“提供”而不是“隐藏”。 我发现CSLA最好的部分就是让你了解所有这些东西是如何实现的，而不是让你自己复制它们。 您可以根据需要select使用尽可能多或less的function，但是我发现通过坚持框架的devise模式，它确实可以让您摆脱困境。 –Byron
我是新来的CSLA，但我理解的概念，我已经明白，这不是一个ORM工具，所以不要打那个该死的鼓人。 有我喜欢的CSLA的function，但使用它们有点像幕后的魔术师。 我想如果你不介意不知道它是如何工作的，那么你可以使用这些对象，他们工作得很好。
对于初学者来说有一个很大的学习曲线，我认为5-15分钟就会大大受益。 像微软这样的video学习基础知识。 或者，如何使用代码发布伴侣书，而不是让代码发布，花费数月的时间才能把书拿出来呢？ 只要在Lohtka先生说…我们开始在书本之前build立我们的东西，我一直在挣扎。 但就像我说的，我是新手。
我们使用CSLA。 我们使我们的物体适合他们的模具，然后使用框架提供的10％。 对象级撤销？ 没有使用它。 NTier的灵活性？ 没有使用它。 我们最终编写了足够的业务规则代码，我认为我们唯一从CSLA中获得的是复杂性。 一些“长齿”的开发者知道这个框架是用它作为他们的锤子，因为他们有一个需要打的钉子。 CSLA是在他们的腰带上，我的猜测是很多框架的支持者也从这个angular度看待事情。
我想我们经验丰富的开发人员很高兴，因为这对他们来说都是有意义的。 我想如果你的组织没有新手程序员，并且你们通过编写高效简单的POCO对象来形成格局良好的模式，那么你就会厌倦。 使用CSLA。
我使用CSLA作为中型项目的业务对象框架。 这个框架从VB6开始已经有了很长的路要走，并且提供了非常多的灵活性和“开箱即用”的function。 CSLA的移动智能对象使UI开发变得更容易。 但是，我同意别人不是每个情况都适合的工具。 这肯定涉及到一些开销，但也有很大的权力。 就我个人而言，我期待着使用Silverlight的CSLA Light。
优点：
- 数据技术不可知1
- 大安装基地，它是免费的！
- 稳定和逻辑的框架
- 数据访问代码可以在您的对象或单独的程序集中
- 属性和对象validation和授权
缺点
- 代码可以很多维护2
- 可能需要一个代码生成器来有效地使用
- 学习曲线。 CSLA对象的结构很容易理解，但是注意事项会造成头痛。
我不确定testing驱动devise。 我不是unit testing或者testing驱动的devise（对我来说是耻辱），所以我不知道unit testing是否与TDD不同，但是我知道框架的最新版本带有unit testing。
1好事，因为数据访问技术永远不会一直保持不变。
2这个框架的最新版本已经变得更好了。
自从VB5以来，我一直在使用CSLA，当时它更像是一个模式集合，而不是一个框架。 随着.NET的推出，CSLA变成了一个全面的框架，带来了一个巨大的学习曲线。 然而，CSLA解决了许多事情，所有的业务开发人员都倾向于在某个时间点（取决于项目范围）编写自己：validation逻辑，身份validation逻辑，撤消function，脏逻辑等等。所有这些事情您可以免费获得框在一个很好的框架。
正如其他人所说，作为一个框架，它迫使开发人员以类似的方式编写业务逻辑。 它也迫使你为你的业务逻辑提供一个抽象层次，所以不使用诸如MVC，MVP，MVVM之类的UI框架变得不那么重要。
事实上，我认为今天（在微软的世界）如此激动人心的UI模式之所以如此激动人心，是因为人们长期以来一直在做着令人难以置信的错误（例如，在你的UI中使用DataGrid，你的业务逻辑无处不在。tisk tisk）。 从一开始就正确devise您的中间层（业务逻辑），您可以在任何用户界面中重新使用您的中间层。 Win Form，ASP.NET / MVC，WCF服务，WPF，Silverlight **，Windows服务，….
但除此之外，对我来说，巨大的回报就是内置的扩展能力。 CSLA使用可通过configuration文件进行configuration的代理模式。 这允许您的业务对象从服务器到服务器进行远程调用，而无需编写一小段代码。 添加更多的用户到你的系统？ 没问题，将你的CSLA业务对象部署到一个新的应用程序服务器，更改configuration文件条目，并且BAM！ 满足即时可扩展性需求
比较这一点，使用DTO的，将您的业务逻辑存储在客户端（无论客户端可能是什么），并不得不写每个自己的CRUD方法作为服务方法。 YIKES！ 不是说这是一个坏的方法，但我不想这样做。 不是当有一个框架，基本上为我做。
我要重申其他人所说的CSLA不是一个ORM。 CSLA强迫您为您的业务对象提供数据。 他们不关心你从哪里得到你的数据。 您可以使用ORM为业务对象提供数据。 您还可以使用原始的ADO.NET，其他服务（RESTFUl，SOAP），Excel电子表格，我可以继续在这里。
至于你对TDD的支持，我从来没有尝试过使用CSLA的方法。 我采用了使用类和序列图对中间层（ala业务对象）build模的方法，通常允许用例，屏幕和/或过程devise来指定。 也许有点老派，但UML一直在我的devise和开发工作中做得很好。 我已经成功地devise和开发了今天仍在使用的非常大且可扩展的应用程序。 直到WCF RIA成熟，我将继续使用CSLA ..
**一些工作
很多人推荐使用CSLA代码生成。 我build议检查我们的支持模板集，因为它们将极大地提高您的投资回报率。
感谢-Blake Niemyjski（ CodeSmith CSLA模板的作者 ）
几年前我用它做了一个项目。 但是项目完成后，我无法告诉任何人CSLA为我做了什么。 当然，我inheritance了它的类。 但是我能够从几乎所有阶级中删除这种inheritance，而不需要重组。 我们没有使用N层的东西。 n级撤销太慢了，我们无法使用它。 所以我想最后它只能帮助我们模拟我们的课程。
话虽如此，其他团队已经开始使用它（经过团队的可怕尝试创build自己的框架）。 所以那里肯定有值得的东西，因为它们都比我聪明！
我是一个PHP的家伙。 当我们开始用PHP构build比较大规模的应用程序时，我开始基本上在PHP世界中研究大量的应用程序框架和ORM，然后在Java和.NET中进行研究。 我也研究过Java和.NET框架的原因不是盲目地使用任何PHP框架，而是首先尝试了解实际发生了什么，以及那里是什么样的企业级架构。
因为我没有在真实世界的应用程序中使用CSLA，所以我不能评论它的优点和缺点，但我可以说的是Lhotka是一位罕见的思想家 – 我不是说软件构架领域的专家。 尽pipe域名驱动devise的名称是由埃文斯·埃文斯（Eric Evans）创造的 – 他的书也很棒，我也谦恭地build议阅读–Lhotka多年来一直在使用域驱动devise。 话虽如此，无论您如何看待自己的框架，都可以从他在这个领域的深刻理念中受益。
您可以在dotnetrocks.com/archives.aspx和dnrtv.com/archives.aspx（searchLhotka）上find他的演讲。
@Byron你喜欢的另外两本书是什么？
约翰，
我们有2到3.5的CSLA团队，他们发现这是一个很好的方式来提供一个一致的框架，所有的开发人员都是这样做的。 大部分低价值的代码是生成的，我们知道当我们运行unit testing的时候，他们可以开箱即用所有的CRUD。 我们发现我们的TDD确实伴随着我们devise的重构，而CSLA并没有阻止我们这样做。
克里斯
我最后试图在VB6的石器时代使用CSLA。 现在回想起来，如果我使用代码生成，它会更有效。 如果你没有有效的代码生成工具和适合他们到你的工作stream程的策略，他们应该避免像CSLA这样的框架，否则你从CSLA获得的function将无法弥补你花费n行的时间每表代码，每列代码行数等。
我已经在几个项目中使用CSLA.NET，它是一个具有丰富的数据绑定兼容性（这是asp.net应用程序没有）的Windows窗体应用程序中最成功。
TDD支持的主要问题是人们一直指出，这是因为Dataportal_XYZ函数的黑盒行为，并且它不能让我们模拟数据对象。 已经努力解决这个问题， 这是最好的方法
我想使用它，但是当时的主要开发者有太多的“魔术”的想法…
CSLA是存在的最好的应用程序框架。 洛基LHotka是一个非常聪明的人。 他正在撰写像Martin Fowler，David S Platt这样的软件开发史，但是我最喜欢的作家是Rod Stephens，Mathew McDonalds，Jeff Levinson，thearon willis和Louis Davidson别名。 :-)优点：所有的devise模式都适用。 缺点：很难学，样本也很less。
