我已经能够实现一些很酷的工作单元来与实体框架一起使用。
我想出了..
public class UnitOfWork : IUnitOfWork
{
private Database _database;
private IDatabaseFactory _databaseFactory;
private DbTransaction transaction;
public UnitOfWork(IDatabaseFactory databaseFactory)
{
_databaseFactory = databaseFactory;
_database = Database;
transaction = _database.Database.Connection.BeginTransaction();
}
public Database Database
{
get { return _database ?? (_database = _databaseFactory.Get()); }
}
public void Dispose()
{
try
{
_database.SaveChanges();
transaction.Commit();
}
catch (Exception ex)
{
transaction.Rollback();
}
}
}
我很确定现在每个人都嫉妒这个工作单元。 (开玩笑)
但我在这个服务层有一些设计问题。
public class JournalService : IJournalService
{
IJournalRepository _journalRepository;
public JournalService(IJournalRepository journalRepository)
{
_journalRepository = journalRepository;
}
public void AjouterJournal(Journal j)
{
[B]using (IUnitOfWork uow = new UnitOfWork())[/B]
{
var journal = new Journal();
journalRepository.AddJournal(journal);
}
}
}
问题是工作单元需要数据库注入,所以我无法创建它的实例。我无法直接在服务层中提供工作单元,因为它没有意义,因为工作单元需要是一次性的。
而且因为我使用存储库来添加我的东西,所以不需要直接访问工作单元,因此当它被处置时,保存将自动发生。
我可以将 IDatabaseFactory 注入到我的服务层中,但想法是不在那里使用它。实际上服务层不应该知道它。
UnitOfWork 工厂怎么样?
关于如何解决这个问题有什么想法或建议吗?
Thanks.
如果您想使用当前的架构,您应该将 UnitOfWork 注入到服务中。您的服务不会对 UnitOfWork 实现有内部(隐藏)依赖,并且可以更好地进行测试。它与面向对象架构的许多原则密切相关。
另一件事是该实现仅可用于简单的 CRUD 操作。在更复杂的服务中,您最终将得到多个操作的组合(可能来自多个服务),每个操作都将使用 UnitOfWork 进行操作。在一个业务操作中调用多个 SaveChanges(和事务)可能不是您通常想要的 - 在这种情况下,您只想从某个顶级服务或服务的调用者调用 SaveChanges 一次。典型场景是单个业务操作具有一个事务的一个工作单元,但您可以将许多服务操作作为该业务操作的一部分。
另一个含义是存储库的构建。他们可能需要访问数据库,不是吗?所以您可能已经将 UoW 注入存储库构造函数中。如果你这样做,你就可以完全避免 UoW 和基本服务之间的关系。
本文内容由网友自发贡献,版权归原作者所有,本站不承担相应法律责任。如您发现有涉嫌抄袭侵权的内容,请联系:hwhale#tublm.com(使用前将#替换为@)