当使用NHibernate从数据库持久化对象时，如何设置其他属性？

我正在创建一个创建文件目录的应用程序。目录的数据将通过NHibernate存储在数据库中，但实际文件仅存储在文件系统中。我已经将文件系统的接口抽象为一个名为

IFileSystemAdaptor

的接口

当从数据库中持久化对象时，我需要设置其

IFileSystemAdaptor FileSystemAdaptor

属性，以便其方法和属性可以访问文件系统

例如，用户以后可能会对持久化对象调用

AddAttachment（字符串文件名、流数据）

。这将导致它通过其

IFileSystemAdaptor

将流写入指定的文件名，并将新文件名添加到其

AttachmenFileNames

属性中，该属性稍后将保存到数据库中

---

在哪里可以插入代码来设置从数据库中持久化的对象的

FileSystemAdaptor

属性？我是否应该在Session/SessionFactory之间添加一个抽象层，在返回对象之前设置

FileSystemAdaptor

属性？或者，是否有某种方法可以将此函数注入到

会话工厂中，使其返回已设置了
文件系统适配器的对象？
我会将其视为基础结构问题。您的业务逻辑可以与IFileSystemAdaptor交互，您可以使用控制反转将FileSystemAdaptor的具体实例传递给您的业务逻辑（接口和具体实例之间的映射将在web.config或app.config中定义）。这将允许您创建传入FileSystemAdaptor模拟实例的单元测试，这样您的业务逻辑就不会依赖于文件系统

我建议在一个专门用于基础设施的层/项目中实现该类，或者可能是一个“应用程序服务”层，用于不一定是业务逻辑的应用程序逻辑。
您可以编写一个IPostLoadEventListener，在从数据库获取实体后设置属性。或者使用将实体注入IFileSystemAdaptor实现。
另一个（可能不受欢迎？）选项可能只是为此使用服务位置。我发现这是一种可以接受的方式，可以向实体提供有限的服务，而不必考虑使用自定义字节码提供程序等的复杂性。
这可能会变得复杂，因为我的程序可能同时打开多个目录，这意味着两个持久化对象可能需要访问不同的IFileSystemAdapter。啊，是的，嗯，我认为有一个很好的理由，你没有走简单（懒惰？）的路线，只是使用服务位置。你可能会想走字节码提供程序路线，正如下面Mauricio所建议的那样…听起来IPostLoadEventListener是最简单的，但是我在NHibernate参考文档中找不到任何关于这个接口的文档，我知道了。以下是我发现的一篇博文：