前几天,我被要求审查一个基于 ASP.NET MVC + CSLA + DDD(域驱动设计)的系统。该系统的第一个版本是基于ASP.NET MVC + CSLA。第二个版本是在此基础上添加了 DDD。原因是……嗯,我不知道是什么。当我查看两种不同架构的图表时,很明显第二个版本极其复杂。 CSLA 对象基本上使用了 Domain 对象。当你看到这样的东西时,你知道它已经闻起来很臭了,但很难证明为什么有人不应该这样做,除非 A) 对所有主题都有深入的了解,或者 B) 长期使用它。对于这个主题,我没有这些,但我知道如果我从头开始构建它,我就不会这样做,我接触的很多开发人员也不会这样做。
那么,亲爱的读者,遇到这种情况你会怎么做?我的想法是,如果您想使用 CSLA、MVC 和 DDD,那么您就表明立场并选择其中之一(CSLA 或 DDD)。如果你不这样做,厨房里就会有太多厨师。
如果您对此事有意见,请发表一些见解。
我的想法是,如果你想
使用 CSLA 和 MVC 和 DDD 然后你就可以了
一个立场并选择一个或另一个(CSLA
或DDD)。如果你不这样做,也有
厨房里有很多厨师。
我倾向于同意你的观点。如果有人想使用已经推出的 DDD 友好架构 + 支持框架来进行 DDD,我建议S#arp 架构 http://www.sharparchitecture.net/通过 CSLA。
尽管如此,有些人认为可以使用 CSLA 来承担 DDD 的某些方面。显然,DDD 纯粹主义者可能会对这种前景感到畏缩,但你不必成为纯粹主义者才能从 DDD 中获得一些东西。 Derick Bailey 有一个关于该主题的有趣博客:http://www.avocadosoftware.com/csblogs/dredge/archive/2007/02/19/687.aspx http://www.avocadosoftware.com/csblogs/dredge/archive/2007/02/19/687.aspx
本文内容由网友自发贡献,版权归原作者所有,本站不承担相应法律责任。如您发现有涉嫌抄袭侵权的内容,请联系:hwhale#tublm.com(使用前将#替换为@)