我公司的主要Web应用程序迫切需要一组漂亮的库,以便以某种方式使其可维护和可扩展,我的一位同事建议CSLA.所以我买了这本书,但是:
程序员不再读书了
我想评估一下SOFlow社区对它的看法.
所以这是我的问题:
人们如何使用CSLA？
优缺点都有什么？
CSLA真的不适合TDD吗？
我有什么选择？
如果你已经停止使用它或决定反对原因？
Brad Leach.. 72
在我专门回答你的问题之前,我想提出一些想法.CSLA是否适合您的项目？这取决于.我个人认为CSLA适用于基于桌面的应用程序,它不会将单元测试视为高优先级.如果您想轻松扩展到n层应用程序,CSLA非常棒.CSLA往往会出现一些问题,因为它不允许纯单元测试.这是真的,不过像技术上的任何东西一样,我相信没有一个真正的方式.单元测试可能不是您为特定项目进行的.对一个团队和一个项目有效的方法可能不适用于其他团队或其他项目.
关于CSLA也存在许多误解.它不是ORM.它不是NHibernate的竞争者(实际上使用CLSA Business Objects和NHibernate作为数据访问非常合适).它规范了移动对象的概念.
1.有多少人在使用CSLA？
基于CSLA论坛,我想说有很多基于CSLA的项目.老实说,我不知道有多少人实际使用它.我过去曾在两个项目中使用它.
2.有什么优点和缺点？
虽然很难在一个简短的列表中总结,但这里有一些想到的优点.
优点:
让新开发人员加快速度很容易.CSLA书籍和示例应用程序是加快速度的重要资源.
验证框架是真正的世界级 - 并且已被许多其他非CSLA项目和技术"借用".
业务对象中的n级撤消
配置n-line可伸缩性的行更改(注意:甚至不需要重新编译)
关键技术是从"真实"代码中抽象出来的.引入WCF时,它对CSLA代码的影响很小.
可以在Windows和Web项目之间共享您的业务对象.
CSLA促进行为的规范化而不是数据的规范化(使数据库保持数据规范化).
缺点:
单元测试困难
缺乏关注点分离(通常您的业务对象中包含数据访问代码).
由于CSLA促进了行为的规范化,而不是数据的规范化,这可能导致业务对象被命名为相似但具有不同的目的.这可能会导致一些混乱,并且感觉您没有适当地重复使用对象.也就是说,一旦实现了生理上的飞跃,它就更有意义了 - 以"旧"的方式构建物体似乎是不合适的.
以这种方式构建应用程序并不是"时尚".您可能很难找到对该技术充满热情的开发人员.
3.看完后,CSLA真的不适合TDD吗？
我还没有找到一种与CSLA进行TDD的有效方法.也就是说,我相信有许多比我更聪明的人可能会尝试更成功.
4.我有什么选择？
Domain-Driven-Design目前正在大力推动(理所当然 - 对某些应用程序而言非常棒).从LINQ(以及LINQ到SQL,实体框架等)的引入中也发展了许多有趣的模式.Fowlers预订PoEAA,详细介绍了许多适合您应用的模式.请注意,某些模式是竞争的(即Active Record和Repository),因此意味着用于特定的场景.虽然CSLA与该书中描述的任何模式都不完全匹配,但它最接近于Active Record(尽管我认为声称与此模式完全匹配是短视的).
5.如果你已经停止使用它或决定反对原因？
我没有完全推荐CSLA用于我的上一个项目,因为我认为应用程序的范围对于CSLA提供的好处来说太大了.
我不会在网络项目中使用CSLA.我觉得还有其他技术更适合在该环境中构建应用程序.
总之,虽然CSLA不是一个灵丹妙药,但它适用于某些场景.
希望这可以帮助!
在我专门回答你的问题之前,我想提出一些想法.CSLA是否适合您的项目？这取决于.我个人认为CSLA适用于基于桌面的应用程序,它不会将单元测试视为高优先级.如果您想轻松扩展到n层应用程序,CSLA非常棒.CSLA往往会出现一些问题,因为它不允许纯单元测试.这是真的,不过像技术上的任何东西一样,我相信没有一个真正的方式.单元测试可能不是您为特定项目进行的.对一个团队和一个项目有效的方法可能不适用于其他团队或其他项目.
关于CSLA也存在许多误解.它不是ORM.它不是NHibernate的竞争者(实际上使用CLSA Business Objects和NHibernate作为数据访问非常合适).它规范了移动对象的概念.
1.有多少人在使用CSLA？
基于CSLA论坛,我想说有很多基于CSLA的项目.老实说,我不知道有多少人实际使用它.我过去曾在两个项目中使用它.
2.有什么优点和缺点？
虽然很难在一个简短的列表中总结,但这里有一些想到的优点.
优点:
让新开发人员加快速度很容易.CSLA书籍和示例应用程序是加快速度的重要资源.
验证框架是真正的世界级 - 并且已被许多其他非CSLA项目和技术"借用".
业务对象中的n级撤消
配置n-line可伸缩性的行更改(注意:甚至不需要重新编译)
关键技术是从"真实"代码中抽象出来的.引入WCF时,它对CSLA代码的影响很小.
可以在Windows和Web项目之间共享您的业务对象.
CSLA促进行为的规范化而不是数据的规范化(使数据库保持数据规范化).
缺点:
单元测试困难
缺乏关注点分离(通常您的业务对象中包含数据访问代码).
由于CSLA促进了行为的规范化,而不是数据的规范化,这可能导致业务对象被命名为相似但具有不同的目的.这可能会导致一些混乱,并且感觉您没有适当地重复使用对象.也就是说,一旦实现了生理上的飞跃,它就更有意义了 - 以"旧"的方式构建物体似乎是不合适的.
以这种方式构建应用程序并不是"时尚".您可能很难找到对该技术充满热情的开发人员.
3.看完后,CSLA真的不适合TDD吗？
我还没有找到一种与CSLA进行TDD的有效方法.也就是说,我相信有许多比我更聪明的人可能会尝试更成功.
4.我有什么选择？
Domain-Driven-Design目前正在大力推动(理所当然 - 对某些应用程序而言非常棒).从LINQ(以及LINQ到SQL,实体框架等)的引入中也发展了许多有趣的模式.Fowlers预订PoEAA,详细介绍了许多适合您应用的模式.请注意,某些模式是竞争的(即Active Record和Repository),因此意味着用于特定的场景.虽然CSLA与该书中描述的任何模式都不完全匹配,但它最接近于Active Record(尽管我认为声称与此模式完全匹配是短视的).
5.如果你已经停止使用它或决定反对原因？
我没有完全推荐CSLA用于我的上一个项目,因为我认为应用程序的范围对于CSLA提供的好处来说太大了.
我不会在网络项目中使用CSLA.我觉得还有其他技术更适合在该环境中构建应用程序.
总之,虽然CSLA不是一个灵丹妙药,但它适用于某些场景.
希望这可以帮助!
在阅读完所有答案之后,我注意到很多人对CSLA有一些误解.
首先,CSLA不是ORM.我怎么能这么说呢？因为Rockford Lhotka在.NET Rocks和Hanselminutes播客的采访中多次表明了这一点.寻找Rocky接受采访的任何一集,他会毫不含糊地说出来.我认为这是人们理解的最关键的事实,因为几乎所有关于CSLA的误解都源于相信它是ORM或试图将其作为一个ORM使用.
正如Brad Leach在他的回答中提到的那样,CSLA反对模型行为,尽管说它们模拟数据行为可能更准确,因为数据是它们不可或缺的.CSLA不是ORM,因为它与您与数据存储的对话完全不可知.你应该使用CSLA的某种数据访问层,甚至是ORM.(我这样做.我现在使用实体框架,它可以很好地工作.)
现在,进行单元测试.我从未对单元测试我的CSLA对象有任何困难,因为我没有将我的数据访问代码直接放入我的业务对象中.相反,我使用了存储库模式的一些变体.存储库由CSLA使用,而不是相反.通过交换虚假存储库进行单元测试并使用本地数据门户,BOOM!这很简单.(一旦实体框架允许使用POCO,这将更加清洁.)
所有这一切都来自于意识到CSLA不是ORM.它可能会消耗一个ORM,但它本身不是一个.
干杯.
我以为我会再发一些评论.
有些人说CSLA比LINQ to SQL等等都要冗长.但在这里我们将苹果与橙子进行比较.LINQ to SQL是一个ORM.它提供了一些CSLA没有的东西,CSLA提供了一些L2S没有的东西,比如集成验证和通过各种远程数据门户的n- tier持久性.其实,我想说的是过去的事情,ñ -tier持久性,胜过他们为我所有.如果我想使用实体框架或LINQ to SQL的过网,我必须把像WCF之间,而且极大地乘以工作和复杂性,在那里我觉得是点多比CSLA更详细.(现在,我是WCF,REST和SOA的粉丝,但是在你真正需要的地方使用它,例如当你想向第三方公开服务时.对于大多数业务线应用程序,它不是确实需要,CSLA是一个更好的选择.)事实上,使用最新版本的CSLA,Rocky提供了一个WCFDataPortal我用过的.它很棒.
我是SOLID,TDD和其他现代软件开发原则的粉丝,并在任何可行的地方使用它们.但我认为CSLA的好处超过了那些正统观察者的一些反对意见,无论如何我已经设法使CSLA与TDD一起工作得很好(并且很容易),所以这不是问题.
是的,我(嗯,我们)广泛使用它来模拟我们的业务流程逻辑,这些逻辑主要是在Windows窗体应用程序中的数据绑定表单.该应用程序是一个交易系统.CSLA旨在位于UI下方的那一层.
如果你认为你的标准的复杂的业务线应用程序,你可以有许多领域,许多规则对这些领域(包括交叉领域的验证规则)形式,你可以调用一个模式对话框编辑一些子对象,你可能希望能够取消此类对话并恢复到以前的状态.CSLA支持这一点.
它的缺点在于它有一点学习曲线.
要记住的关键是使用CSLA来模拟用户如何与某些应用程序上的表单进行交互.对我来说最有效的方法是在构建CSLA对象之前设计UI并理解它的流程,行为和验证规则.没有你的CSLA对象驱动UI设计.
我们还发现能够使用CSLA业务对象服务器端来验证从客户端发送的对象非常有用.
我们也有内置的机制来对Web服务异步执行验证(即检查对方的反对主的信用额度范围内).
CSLA强制执行你的UI,BusinessLogic和持久性之间有很强的分离与我们写的对他们的单元测试的负载.它可能不是严格的TDD,因为你是从UI设计驱动它,这并不意味着它是不可测试的.
唯一真正的选择是创建自己的模型\业务对象,但很快你就会是里昂证券提供开箱即用的功能实现(INotifyPropertyChanged的,IDataErrorInfo的,pushState的,PopState等)
我已经将CSLA用于一个项目,它工作得很好,使事情更简单,更整洁.
我们知道有一个共同的标准可以反对,而不是让你的团队以自己不同的个人风格编写业务对象.
//安迪
几年前我有过这方面的经验.它是一个出色的架构,但非常复杂,难以理解或改变,它解决了我们大多数开发基于Web的应用程序不一定有的问题.它是为基于Windows的应用程序开发的,并且处理多级撤消,重点强调事务逻辑.您可能会听到有人说,由于Web应用程序在页面级别是请求 - 响应,这是不合适的,但是对于AJAX风格的Web应用程序,这个论点可能没有那么多水.
它有一个非常深的对象模型,它可能需要一段时间来真正包裹你的大脑.当然,很多都可以在几年内改变.我很想知道最近的其他意见.
考虑到所有因素,它不是我的首选架构.
为了捍卫CSLA,虽然我同意许多评论特别是单位测试一个......
我的公司广泛用于Windows Forms数据输入应用程序,取得了很大的成功.
它提供了开箱即用的功能,我们没有时间或专业知识来写自己.
它标准化了我们所有的业务对象,使维护变得简单,并减少了新开发人员的学习曲线.
总的来说,我会说它引起的任何问题都不仅仅是好处所带来的.
更新:除此之外,我们仍然将它用于我们的Windows窗体应用程序,但将其用于其他应用程序(如网站)的实验表明,当您不需要其功能并且我们正在调查时,它可能很麻烦这些场景的重量较轻的选项.
我加入了一个CSLA强制要求的团队.我们不使用远程数据门户,这是我同意使用此框架的唯一原因.我从来没有接受过CSLA的想法,所以也许这就是为什么我只有它的问题,对不起.
一些问题:
我不需要在我的代码和.NET框架之间存在障碍,这就是这个框架对我的感觉.我有一个有限的列表对象选项,而我只需要忽略.NET框架中的丰富列表对象.
Ii完全是荒谬的,我们有这些只读列表,然后是非只读列表.所以,如果我必须在列表中添加一个项目,我必须重新创建整个列表......你认真吗？
然后csla想要管理我的对象状态,这很好,但没有真正暴露.有时我想手动更改对象状态而不是再次获取它,这似乎是csla希望我做的事情.我基本上最终创建了许多属性来公开选项csla认为我不应该直接访问.
为什么我不能实例化一个对象？我们最终创建了静态方法,它实例化一个对象并将其传回去...你在开玩笑吧？
检查框架源代码,它看起来对我的反射代码很重要.
使用csla的原因:
直接的.net框架对你来说太强大了.
你的开发人员没有经验丰富,无法掌握模式的概念,那么csla几乎每个人都在同一页面上.
我的代码和.NET框架之间不需要路障......我对这些列表对象感到困惑.
我们开始使用CSLA,因为我们认为它对我们的模型层有帮助.有点矫枉过正,我们现在使用的大部分都是SmartDate类,因为我们已经链接到了库.
我们认为验证接口确实可以帮助我们实施业务规则,但它在WCF和序列化方面效果不佳(我们仍然坚持使用版本2.0.3.0,所以事情可能已经改变).
我们公司在一些项目中实践了CSLA,一些遗留项目仍然是CSLA.其他项目远离它,因为CSLA违反了简单明了的OOP规则:单一责任原则.
CSLA对象是自我维持的,例如,他们检索自己的数据,他们管理自己的行为,他们自己保存.不幸的是,这意味着您的平均CSLA对象至少有三个职责 - 代表域模型,包含业务规则,并且包含数据访问定义(不是DAL,或数据访问实现,如我之前所述/暗示的)都在同一个时间.
不要将CSLA列入清单,但在使用之前,请研究好处并确保它们确实适用.您的团队能否正确/一致地实施它？需要远程和门户舞蹈吗？
我认为,除了所有的理论思考之外,它都是关于基本经过验证的模式的清洁/可维护/可扩展/可测试代码.
我计算了从CSLA转换的项目的特定域中所需的代码行.在所有不同的CSLA对象(readonly + editable + root + list组合)和它们存储的proc之间它占用了大约1700行,而Linq2SQL + Repository实现需要180行.Linq2SQL版本主要由生成的类组成,您的团队不需要使用本书来理解.是的,我使用CodeSmith来生成CSLA部分,但我现在相信具有单一责任位的DRY代码,而CSLA实现现在看起来像昨天的英雄.
作为替代方案,我想建议查看Linq2Sql/Entity Framework/NHibernate结合Repository和UnitOfWork模式.看看http://www.codeplex.com/backgroundmotion
干杯!
我们广泛使用CSLA。有几个好处；首先，我相信每一个业务开发人员都应该阅读Rocky Lhotka关于Business Objects编程的书。我个人发现它在我的前三本最佳编程书籍中。CSLA是基于本书的框架，使用它可以使您的项目访问非常高级的功能，例如n级撤消，验证规则和可伸缩性体系结构，同时为您提供详细信息。注意，我说的是“提供”而不是“隐藏”。我发现CSLA最好的部分是让您了解如何将所有这些事情实现到源代码，而无需您自己复制它们。您可以选择使用所需的功能，但我发现通过忠于框架的设计模式，它确实使您摆脱麻烦。-拜伦
京公网安备 11010802040832号 | 京ICP备19059560号-6 