NHibernate和存储库设计模式

我已经和NHibernate合作了很长一段时间，并且逐渐意识到我的架构可能有点…过时了。这是一个NHibernate库，它生活在几个相互关联的应用程序后面

首先，我有一个带有ID和EntityID的DomainEntity基类（这是我在向web或通过API公开项目时使用的guid，而不是内部整数ID-我想我有过这样做的原因，但我不确定它现在是否真的有效）。我有一个存储库基类，其中T继承自DomainEntity，它提供了一组通用搜索方法。DomainEntity的继承者还可以实现几个接口，这些接口跟踪诸如created date、created by等内容，这些内容主要是对象最新更改的日志。我不喜欢为此使用存储库模式，但它包装了保存对象时设置这些值的逻辑（前提是对象通过存储库保存，而不是作为保存其他内容的一部分保存）

---

我想摆脱这些知识库。它们让我不高兴，而且最近看起来真的很混乱，特别是现在我不使用hql查询，现在我可以在会话对象上使用扩展方法。但是我如何将这类功能清晰地连接起来呢？为了便于讨论，让我们假设我已经设置了structuremap之类的东西，并且能够返回一个公开上下文信息的对象（当前用户等），那么在存储库结构之外提供此功能的一种灵活方式是什么呢？如果可以将其与基于约定的映射设置（我也在考虑替换XML文件）连接起来，则会有额外的好处。

如果您不喜欢存储库随着时间的推移可能会变得臃肿，那么您可能希望使用类似的方法

基本思想是将单个查询分解为单个对象，然后将其应用于数据库

---

一些示例实现链接。

查询端的处理相当简单，可以通过查询对象，也可以通过扩展方法（我不确定我更喜欢哪一种-我将不得不进行实验）。如果我能弄清楚命令端，我就可以完全摆脱存储库。