如何在n层架构中解决这个NHibernate查询?

Tyl*_*ght 2 c# nhibernate onion-architecture

我试图将NHibernate从我的服务层分离出来.我的架构看起来像这样:

web - > services - > repositories - > nhibernate - > db

我希望能够从我的服务层和可能的我的web层产生nhibernate查询,而不知道那些层知道他们正在处理什么样的orm.目前,我在我的所有存储库中都有一个find方法IList<object[]> criteria.这允许我传递一个标准列表,例如new object() {"Username", usernameVariable};从我的架构中的任何地方.NHibernate接受它并创建一个新的Criteria对象并添加传入的标准.这适用于我的服务层的基本搜索,但我希望能够传入我的存储库转换为NHibernate Criteria的查询对象.

真的,我很乐意实现类似于这个问题所描述的内容:抽象nhibernate标准是否有价值.我只是没有找到任何关于如何实现这样的东西的好资源.该问题中描述的方法是一种好方法吗?如果是这样,有人可以提供一些关于如何实施这样的解决方案的指示吗?

Fir*_*iro 9

抽象出ORM将:

  • 带来了很多重新定义API的工作
  • 无法优化/批量数据库访问
  • 使得理解执行哪些查询变得更加困难
  • 将导致大量的SELECT N + 1

并且所有这些都是非常有价值的:交换ORM框架的模糊选项很可能会有很多其他问题

  • 缺少功能
  • 实施中的细微差别
  • 学习曲线

更新:经验

我曾经参与实现现有DAL抽象的新提供者.它最终表现不佳,引入了很多错误,错误处理是一团糟,有时使用陈旧数据,因为应用程序采用了默认实现.原因:

  • 缓存不知道上下文
  • Cacheimlementation具有不同的语义
  • 批处理API太不同了,不能被抽象化
  • 错误特定于实现(例如,FileNotFound - > FilesearchDialog对于基于tcp/ip的数据库是无用的)
  • 错误恢复是不同的(每个实现都有自己可以从中恢复的错误集)
  • 锁定机制不同
  • SQL数据库中没有一致的更改事件
  • 嵌套事务
  • 模型类中的默认实现已消失
  • 重新实现所有抽象的Queryies是很多工作,并引入了很多复制粘贴错误
  • 在没有明确说明顺序的情况下查询将在不同的实现中返回不同的有序结果

它花了很多重构应用程序:

  • 剥离功能只有一个实现提供
  • 每个实现的缓存管理
  • 由于瞬态数据导致的Wrappers身份问题
  • 实现对两个数据存储区的查询非常困难

附加要点:

  • 通过抽象DAL迁移数据的速度很慢
  • 实现另一个实现将永远不会发生,因为上述问题太昂贵(在上述场景中我们开始慢慢重新实现整个项目)
  • 实现DAL API的正确语义极其困难,因为纯API中没有使用上下文

移植(业务任务)对IMO的影响要小得多,因为我们因为性能而为少数人做了这样的事情.

Update2:experience2:尝试从NHibernate移植到EntityFramework时尝试使用RoadBlocks(使用NH进行移植但在合理时间内无法使用EF 4)

  • 嵌套交易
  • 枚举支持
  • 使用compositeId引用(如何摆脱referenceIds)
  • 组件中的引用
  • 阅读批量(期货),这对于页面+计数一次性非常方便
  • 映射CultureInfo(IUserType支持)