nhibernate - C# 事件记录实现

Question

我偶然发现了Castle Active Record几周前，我认为它看起来像是一个有趣的解决方案，可以解决与数据驱动应用程序相关的繁重 CRUD 任务。它现在看起来相当成熟，我正在考虑将它用于我正在开发的应用程序的数据层，但我想知道:

1. 它的扩展能力如何？ (即 NHibernate 上的额外层是否可以很好地扩展)
2. 一旦您已经进入开发阶段而无法轻易改变方向，它的最大限制是什么，会导致您感到沮丧？
3. 使用不带 Active Record 层的直接 NHibernate 是更好的长期选择吗？

Answer 1

就我个人而言，我认为 Active Record 模式本身和 CaSTLe 的宝贝肯定有一些优点，例如:

• 简化配置
• AR 模式 - “实体是独立的”。有时，项目比其他任何事情都重要。
• 您可以在项目中快速开始开发和使用 AR。只需定义适当的映射，添加一些配置，您就可以对实体执行一些基本操作。对我来说，这部分似乎比纯粹的 nh 更快。
• AR 中的 SessionScope + TransactionScope 类已经为您准备好了。如果您必须这样做，则必须自己为 nh 编写此内容。支持事务继承。
• 所有 CaSTLe 项目都能完美地协同工作。 AR + 设施 + 温莎 = 非常强大的堆栈。
• 有新版本的 AR(终于!)在 NH 3.0 之上运行。

但也有一些缺点:

• 开销的神话。我觉得这不是我可以定义的东西，但就是感觉所有这些 session 管理、包装器等都必须付出一些代价。但我认为实际上这是非常难以捉摸的。
• 如果你需要做一些定制的事情，你只需要接触 nhibernate 的内核即可。 AR 似乎相当复杂。
• 不支持第二缓存
• AR 映射不是 POCO。通过 WCF 序列化或仅在不同层之间发送时可能会出现问题。 NH 的情况并非如此。
• AR 并不是强制存储库/dao 类采用 OO 方法的最佳方式。但这并不是什么新鲜事，因为它纯粹是 AR 模式的结果——你的对象知道如何保存或删除自己。但当你的项目变得更大一点时，这就变得很痛苦。

所以最后，它是一个很好的框架，可以用于简单或中等复杂的项目。这对 asp.net/winforms 来说很好，没关系。使用纯 NH，您肯定需要编写更多代码才能创建类似的应用程序。但如果你愿意这么做，你会更快乐。因为你将能够控制一切。

一如既往，这完全取决于您的偏好或项目。对于小型、快速的项目 - AR 是方法，对于中型项目 - 我想说 NH 是方法!

附: 哦，顺便说一下，AR 进行完全相同的查询，所以就像使用 nh 与 db 对话一样。 NH 规模如此，城堡亦然。只要避免“n+1”问题并考虑懒惰，你就应该很好；P

附: 听听 Mauricio Scheffer 的说法，他真的知道自己在写什么。