当前位置：文江博客话题详情

如何抽象 NHibernate 以避免紧密依赖并促进测试

发布于 2024-08-25 01:15:55 字数 512 浏览 8 评论 0原文

是否可以采用像NHibernate或Entity Framework这样的O/RM，并以这样的方式进行抽象，以便在遇到O/RM无法处理的情况时可以替换它。

创建一个具有大块服务方法的服务似乎很诱人，在该服务中创建一个会话，该会话用于获取/更新插入实体，然后用于保存所有脏对象。

我会考虑存储库模式，以便服务操作向存储库请求实体，并且 O/RM 会话嵌入在存储库中。但是，如何保存相关实体，以及 Update(T 实体) 方法是否立即刷新更改。它看起来很简单，而且通常不能令人满意。

我现在倾向于的是一个单一的 O/RM 包装类，它公开一个具有通用方法的接口，如“StartSession”、“EndSession”、“AbandonSession”、“GetById(object id)”等。

至少这将允许 OR /M 在测试中被伪造，这是我的另一个大问题。

我想我是说我不想将业务逻辑和 O/RM 数据访问代码紧密地交织在一起，因为切换到另一个 O/RM 可能会导致大部分代码被替换。

人们在现实世界中做什么？

原文

分享到QQ

分享到微博

如果你对这篇内容有疑问，欢迎到本站社区发帖提问参与讨论，获取更多帮助，或者扫码二维码加入 Web 技术交流群。

发布评论

需要登录才能够评论，你可以免费注册一个本站的账号。

我们只是彼此的过ke 2024-09-01 01:15:55

我强烈的意见是对较小的项目进行一些测试，并选择一个预先使用的工具集，而不是通过构建一个“有一天”能够更改的抽象包装器来推迟决定，直到稍后。根据我的经验，这一天永远不会到来，并且您引入的复杂性是不值得的。

我过去曾尝试为 nHibernate 构建一个通用包装器，但基本上除了痛苦之外什么也没遇到。 ORM 工具本身实际上是一个包装器和工具集。当您尝试创建包装器的包装器时，您最终需要开发（并随后维护）相对复杂的工具和机制来完成您要包装的事物本身的功能。

而且，根据我自己的经验，我花费大量时间构建的包装器最终只暴露了底层 ORM 工具的一小部分功能。然后我从来没有将包装器与除 nHibernate 之外的任何东西一起使用......所以我可以通过仅使用普通 nHibernate 本身来节省大量的时间和精力。

我建议仔细研究您的需求，而不是花时间抽象出瑞士军刀解决方案，而是进行研究，首先选择一个工具集并使用它运行。是的，您的代码将与第三方工具紧密耦合，但代码会更简单，您会更快地实现目标，并且结果可能会更好。

希望有帮助，

马克斯·席林

回复收藏 0 原文

红玫瑰 2024-09-01 01:15:55

我使用工作单元模式处理数据库的 C/U/D 事务。在抽象方面我不会做更多的事情，因为我不想抽象抽象的抽象。 Linq 是查询部分的一个很好的抽象，通用存储库是查询部分的一个很好的抽象。这些是我在几乎所有具有关系数据库的项目中使用的抽象：

interface IRepository<T> : IQueryable<T>
{
   void Add(T entity);
   void Remove(T entity);
   T Get(Guid id);
}

interface IUnitOfWork : IDisposable
{
   void RollBack();
   void Commit();
}

// I don't do this every time, the generic repository is enough for almost everything.
[Example]
interface IOrderRepository : IRepository<Order>
{
   IList<Order> GetOrdersForUser(User user);
}

// This interface is only used in the repository implementation
interface INHiberanteUnitOfWork : IUnitOfWork
{
  ISession Session { get; }
}

有时，我使用通用存储库，有时我使用具有规范模式支持的更具体的通用存储库，有时我为特定实体类型创建单独的存储库。
您可以在 NHibernate + 工作单元上搜索堆栈溢出，以查找有关实现这些模式的更多信息。

我不对映射进行抽象，因为每个orm在映射方面都有自己的特点，我认为映射已经是一个抽象了。我使用 Fluentnhibernate 进行映射。

I handle C/U/D transactions to the database with the unit of work pattern. I don't go much further than that in abstracting, because I don't want to abstract the abstraction of the abstraction. Linq is a good abstraction for the querying part, a generic repository is a good abstract for the querying part. These are the abstractions I use in almost any project with a relational database:

interface IRepository<T> : IQueryable<T>
{
   void Add(T entity);
   void Remove(T entity);
   T Get(Guid id);
}

interface IUnitOfWork : IDisposable
{
   void RollBack();
   void Commit();
}

// I don't do this every time, the generic repository is enough for almost everything.
[Example]
interface IOrderRepository : IRepository<Order>
{
   IList<Order> GetOrdersForUser(User user);
}

// This interface is only used in the repository implementation
interface INHiberanteUnitOfWork : IUnitOfWork
{
  ISession Session { get; }
}

Sometimes, I use the generic repository, sometimes I use a more specific generic repository with specification pattern support, and sometimes I create a separate repository for a specific entity type.
You can search stack overflow on NHibernate + Unit of work to find more information about implementing these patterns.

I don't abstract the mapping, because every orm has it's own features in mapping, and I think the mapping is already an abstraction. I use fluentnhibernate for mapping.

回复收藏 0 原文