有人在 NWorkspace 模式上取得了成功吗?

发布于 2024-11-03 22:14:05 字数 460 浏览 3 评论 0原文

我刚刚开始深入研究域驱动设计的第一个实验,并且正在利用 NWorkspace 模式。这种模式似乎很有意义,但是我无法找到很多成功使用该模式甚至公开记录该模式的示例。在深入实施之前,我想知道是否有人使用此模式取得了成功,或者是否有人可以向我指出在任何开源项目中使用 NWorkspace 的任何参考资料,我可以从中学习。我还应该了解这种模式的更好或更广为人知的替代方案吗?

NWorkspace 简介

对于那些可能不熟悉 NWorkspace 的人来说,这是 Jimmy 引入的一种模式Nisson 的 抽象了查询和持久化职责。 Jimmy Nilsson 在他的《应用领域驱动设计和模式》一书中展示了如何使用 NWorkspace 来抽象 DDD 存储库的基础设施部分,并提供一种机制来执行与持久性相关的跨存储库原子性。

I've just begun to delve into my first experiments with Domain Drive Design and I'm taking advantage of the NWorkspace pattern. This pattern seems to make a lot of sense however I haven't been able to find very many examples of places this pattern has been successfully used or even publicly documented. Before I get to far into my implementation I would like to know if anybody has had success using this pattern or whether somebody could point me to any references where NWorkspace has been used in any open source project that I could learn from. Also are there better or more well known alternatives to this pattern that I should know about?

Brief background on NWorkspace

For those who may not be familiar with NWorkspace, it is a pattern introduced by Jimmy Nisson's which abstracts query and persistance responsibilities. In his book Applying Domain-Driven Design and Patterns, Jimmy Nilsson shows how NWorkspace can be used to abstract the infrastructure portions of a DDD Repository as well as provide a mechanism to perform cross Repository atomicity with regard to persistence.

如果你对这篇内容有疑问,欢迎到本站社区发帖提问 参与讨论,获取更多帮助,或者扫码二维码加入 Web 技术交流群。

扫码二维码加入Web技术交流群

发布评论

需要 登录 才能够评论, 你可以免费 注册 一个本站的账号。

评论(1

晚雾 2024-11-10 22:14:05

看起来他建议使用单独的接口来读取和写入存储库。
我没有所描述的模式的经验,但我建议不要进行跨存储库事务。相反,我会建议一些在 DDD 社区(Eric Evans、Udi Dahan、Greg Young)中流行的解决方案,这些解决方案确实对我有帮助:

  1. 始终在聚合根上使用急切加载。那么你就不需要跨存储库的原子性,并且弄清楚当你持久化对象时发生了什么变化就容易得多。
  2. 使用单独的类进行写入(即域类)和读取(即您的视图模型)。创建直接从数据库检索视图模型的视图模型存储库(而不是将域对象映射到视图模型类)。

看看实施上述两件事是否可以简化您的设计。

It seems like he's recommending separate interfaces for read and write repositories.
I don't have experience with the pattern described, but I would recommend not having cross-repository transactions. Instead, I would suggest a few solutions popular amongst the DDD community (Eric Evans, Udi Dahan, Greg Young) that have really helped me:

  1. Always use eager loading on your aggregate roots. Then you don't need cross-repository atomicity, and figuring out what's changed when you persist the object is a lot easier.
  2. Use separate classes for writing (i.e. domain classes) and reading (i.e. your viewmodel). Create view model repositories that retrieve viewmodels directly from the database (instead of mapping domain objects to view model classes).

See if implementing the above 2 things simplifies your design.

~没有更多了~
我们使用 Cookies 和其他技术来定制您的体验包括您的登录状态等。通过阅读我们的 隐私政策 了解更多相关信息。 单击 接受 或继续使用网站,即表示您同意使用 Cookies 和您的相关数据。
原文