如何从现有的 ADO.NET 持久性逻辑逐渐过渡到 NHibernate 持久性逻辑？

Question

应用程序使用 ADO.NET 为几乎每个数据库操作调用存储过程。其中一些存储过程还包含相当数量的域逻辑。每个域实体的数据访问逻辑驻留在域类本身中。即，域逻辑和数据访问逻辑之间没有解耦。

我希望完成以下工作：

• 将域逻辑与数据访问逻辑解耦
• 让域模型持久化无知
• 在各个版本中逐步实现向 NHibernate 的过渡，一次重构 DAL 的各个部分（如果可以这么称呼的话）

这是我将单个类转换为 NHibernate 持久性的方法

1. 为域类创建映射
2. 为域类创建一个存储库（从通用基础存储库继承的基本 CRUD 操作）
3. 在存储库中为旧 DAL 使用的每个存储过程创建一个方法（沿途进行一些重构以提取域逻辑）
4. 修改消费者使用存储库而不是类本身的数据访问逻辑
5. 删除旧的数据访问逻辑和存储过程

我遇到的问题是 #1 和 #4。

(#1) 如何映射没有 NHibernate 映射的类型的属性？

考虑一个带有 Address 属性的 Person 类（Address 是一个没有 NH 映射的域对象，而 Person 是我正在映射的类）。如何在不为地址创建整个映射的情况下将地址包含在人员映射中？

(#4) 在过渡期间我应该如何管理对旧数据访问逻辑的依赖？

域模型中的类利用了我希望删除的旧数据访问逻辑。考虑一个带有 CustomerId 属性的 Order 类。当 Order 需要有关 Customer 的信息时，它会调用 Customer 类中的 ADO.NET 数据访问逻辑。除了维护旧的数据访问逻辑直到依赖类被自己映射之外，还有什么选择？

Answer 1

我会这样处理它：

1. 重构并将数据访问逻辑从域类移到数据层中。
2. 重构并将域逻辑从存储过程中移到数据层中。 （这一步是可选的，但这样做肯定会使过渡更顺畅、更轻松。）
3. 您不需要存储库，但您当然可以根据需要创建一个。
4. 为每个域类创建一个 NHibernate 映射（有工具可以做到这一点）。
5. 创建一个面向 NHibernate 的数据访问 API，它会慢慢替换 sproc 数据层。

第 1 步和第 2 步是最难的部分，因为听起来您的紧密耦合在理想情况下永远不会发生。前两个步骤都不涉及 NHibernate。在尝试换出数据层之前，您将严格转向更易于维护的架构。

虽然可以一个一个地创建 NHibernate 映射并在没有完整对象图可用的情况下使用它们，但这似乎是在要求不必要的痛苦。如果您选择该路径，则需要非常谨慎地进行，我只是不推荐它。为此，您可以将外键映射为普通的 int/guid，而不是作为与另一个域类的关系，但是您必须非常小心，不要以这种方式将一半提交给 NHibernate 来破坏您的数据。自动化单元/集成测试是您的朋友。

交换数据层很困难。如果你有一个可靠的最低公分母数据层架构，那就更容易了，但我实际上并不建议使用最低公分母方法创建一个架构。松散耦合很好，但你可能会走得太远。

Answer 2

在互联网上搜索更多休眠电子书

1. 重构并将数据访问逻辑从域类移到数据层中。
2. 重构并将域逻辑从存储过程中移到数据层中。 （此步骤是可选的，但这样做肯定会使过渡更加顺畅和轻松。）
3. 您不需要存储库，但您当然可以根据需要创建一个。
4. 为每个域类创建 NHibernate 映射（有工具可以做到这一点）。
5. 创建一个面向 NHibernate 的数据访问 API，慢慢替换 sproc 数据层