前几天我被要求审查一个基于 ASP.NET MVC + CSLA + DDD（域驱动设计）的系统。该系统的第一个版本基于 ASP.NET MVC + CSLA。第二个版本基于那个加上添加的 DDD。原因是因为......好吧，我不知道是什么。当我查看两种不同架构的图表时，很明显第二个版本非常复杂。CSLA 对象基本上使用域对象。当你看到这样的东西时，你就知道它已经闻起来了，但是如果没有 A) 对所有主题的极端了解或 B) 长时间使用它，很难证明为什么有人不应该这样做。对于这个主题，我没有这些，但我知道如果我从头开始构建它，我就不会这样做，也不会
那么，亲爱的读者，在这种情况下你会怎么做呢？我的想法是，如果你想使用 CSLA、MVC 和 DDD，那么你就站出来选择一个或另一个（CSLA 或 DDD）。如果你没有厨房里的厨师太多。
如果您对此事有意见，请提供一些见解。
我的想法是，如果你想使用 CSLA、MVC 和 DDD，那么你就站出来选择一个或另一个（CSLA 或 DDD）。如果你没有厨房里的厨师太多。
我倾向于同意你的观点。如果有人想用已经淘汰的 DDD 友好架构 + 支持框架来做 DDD，我会推荐S#arp 架构而不是 CSLA。
话虽如此，有些人认为可以使用 CSLA 承担 DDD 的某些方面。显然，一个 DDD 纯粹主义者可能会对这种前景感到畏缩，但您不必成为一个纯粹主义者就可以从 DDD 中获得一些东西。Derick Bailey 有一个关于该主题的有趣博客：http ://www.avocadosoftware.com/csblogs/dredge/archive/2007/02/19/687.aspx
在我看来，CSLA 以最新版本自爆。意见不同，但在我的书中，当一个对象必须知道它是否是一个孩子时，这是非常错误的。
似乎有些人发现 CSLA 和 DDD / Alt.Net 并不完全是交叉用途。
我仍然同意，如果你决定走一条更纯粹、不那么务实的道路，你可能还有很多工作要做，以适应 Rocky 所做的出色工作，正如 Keith 所建议的那样，它可能是如果您不小心，很容易造成混乱。
一些进一步的信息：
我不确定从内存中使用 ActiveRecord 方法的 CSLA 是否特别适合 DDD。最好使用 nHibernate。