贫乏的领域模型和 ObjectDataSource
我最近意识到我正在使用贫血模型创建 n 层应用程序，许多人认为这不是正确的 OO 做事方式（而且它实际上是一种反模式）。
所以我现在尝试应用领域驱动设计。
我习惯于使用对象数据源将控件（例如网格视图）绑定到我的业务对象。 我对如何将对象数据源与域模型一起使用感到困惑。 objectdatasource 是否需要贫血模型？
我正在考虑删除所有对象数据源，无论如何我发现它有时都是一种负担（特别是在调试代码和异常处理时），但我想知道“正确”的做事方式是什么。
I recently realized that I'm creating my n-tier applications using the Anemic Model, Which many would argue is not the proper OO way of doing things (and that it is actually an anti pattern).
So I'm now trying to apply the Domain-Driven Design instead.
I'm used to using the objectdatasource to bind controls, such as the grid view, to my business objects.
I'm confused as to how i would use the objectdatasource with the domain model. does the objectdatasource require an anemic model?
I was considering removing all objectdatasources, I find it to be a burden at times anyway (especially when it comes to debugging code and exception handling), but I'd like to know what the 'proper' way of doing things is.
如果你对这篇内容有疑问，欢迎到本站社区发帖提问 参与讨论，获取更多帮助，或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱，如果其他用户或者作者回复了您的评论，将不能在第一时间通知您！
发布评论
评论（2）
尽管我对 ASP.NET 没有太多经验，但我认为数据绑定总体来说还是很不错的。它给你带来很多好处，所以不要轻易丢弃它。
关键是要分离关注点。呈现数据的方式与域模型本身无关，因此更好的设计是有一个专门的表示逻辑层将域模型映射到视图。
这意味着您可以保持领域模型技术中立，以便能够以许多不可预见的方式公开它。想象一下，将来你会被要求实现一个WCF服务，或者一个批处理作业，或者一个基于领域模型的WPF/SL富客户端。它应该能够处理此类不可预见的需求，而不会拖累与任何特定 UI 技术（例如 ASP.NET）相关的许多特性。
当您的每个视图都有ViewModels或演示模型时，您可以对这些模型使用数据带。我不知道这在 ASP.NET 中效果如何，但它在 ASP.NET MVC 和 WPF 中都非常有用，并且目前 Silverlight 4 中已内置对此的支持...
I think that databinding in general rocks, although I don't have much experience with ASP.NET. It gives you a lot of benefits, so don't discard it too easiliy.
The key is to separate concerns. How you render data has nothing to do with the Domain Model itself, so a better design is to have a specialized Presentation Logic layer that maps the Domain Model to Views.
This means that you can keep your Domain Model technology-neutral so that you would be able to expose it in a lot of unforseen ways. Imagine that in the future, you will be asked to implement a WCF service, or a batch job, or a WPF/SL rich client based on the Domain Model. It should be able to handle such unforseen requirements without dragging along a lot of peculiarities tied to any particular UI technology (such as ASP.NET).
When you have ViewModels or Presentation Models for each of your Views, you can use databanding against those models. I don't know how well this works in ASP.NET, but it works like a charm in both ASP.NET MVC and WPF, and the support for that is currently being built into Silverlight 4...
就我个人而言，在判断一个物体是否贫血时，我并不太关心排除持久性。对象的业务行为应该与它是否持久以及如何持久相关。
行为应该与有助于解决根本问题的功能有关。在设计更多是传输值对象的对象时，我会专注于这一点，而不用担心 CRUD 操作。
Personally, I'm not much concerned about excluding persistence when judging an object's anemia. The business behavior of an object should be orthogonal to whether or not it's persistent and how it persists.
Behavior should be about the functionality that helps to solve the root problem. I'd concentrate on that when designing objects that are more the transfer value objects and not worry about CRUD operations.