我最近意识到我正在使用贫血模型创建我的 n 层应用程序，许多人认为这不是正确的 OO 做事方式（而且它实际上是一种反模式）。
所以我现在尝试应用领域驱动设计。
我习惯于使用 objectdatasource 将控件（例如网格视图）绑定到我的业务对象。我对如何将 objectdatasource 与域模型一起使用感到困惑。objectdatasource 是否需要贫血模型？
我正在考虑删除所有对象数据源，我发现它有时是一种负担（尤其是在调试代码和异常处理方面），但我想知道“正确”的做事方式是什么。
我认为数据绑定在一般情况下很重要，尽管我对 ASP.NET 没有太多经验。它给你很多好处，所以不要太容易丢弃它。
关键是分离关注点。如何呈现数据与域模型本身无关，因此更好的设计是拥有一个专门的表示逻辑层，将域模型映射到视图。
这意味着您可以保持您的领域模型技术中立，以便您能够以许多不可预见的方式公开它。想象一下，在未来，你会被要求实现一个 WCF 服务，或者一个批处理作业，或者一个基于域模型的 WPF/SL 富客户端。它应该能够处理这些不可预见的需求，而不会拖累与任何特定 UI 技术（例如 ASP.NET）相关的许多特性。
当每个视图都有ViewModels或Presentation Models时，您可以对这些模型使用数据带。我不知道这在 ASP.NET 中的效果如何，但它在 ASP.NET MVC 和 WPF 中都像一个魅力，并且目前正在将对此的支持内置到 Silverlight 4 中......
就个人而言，在判断一个对象的贫血时，我不太关心排除持久性。一个对象的业务行为应该与它是否持久以及它如何持久是正交的。
行为应该与有助于解决根本问题的功能有关。在设计更多是传递值对象而不担心 CRUD 操作的对象时，我会专注于这一点。