Rus*_*ino 5 .net entity-framework unit-of-work entity-framework-ctp5
我已经能够实现一个很酷的工作单元来处理实体框架.
我想出了..
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();
}
}
}
Run Code Online (Sandbox Code Playgroud)
我很确定现在每个人都嫉妒这个工作单位.(开玩笑)
但是我在这个服务层有一点设计问题.
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);
}
}
}
Run Code Online (Sandbox Code Playgroud)
问题是工作单元需要数据库注入,所以我无法创建它的实例.我无法直接在服务层提供工作单元,因为工作单元需要是一次性的,因此没有意义.
而且因为我使用存储库来添加我的东西,所以不需要直接访问工作单元,无论如何都会自动进行保存.
我可以在我的服务层注入IDatabaseFactory,但想法是不在那里使用它.实际上服务层不应该知道它.
UnitOfWork工厂怎么样?
关于我如何解决这个问题的任何想法或建议?
谢谢.
如果要使用当前的体系结构,则应将UnitOfWork注入服务.您的服务不会对UnitOfWork实现具有内部(隐藏)依赖性,并且它将更易于测试.它与面向对象架构的许多原则密切相关.
另一件事是这个实现只适用于简单的CRUD操作.在更复杂的服务中,您最终会得到多个操作的组合(可能来自多重服务),每个操作都使用UnitOfWork.在一个业务操作中调用多个SaveChanges(和事务)可能不是您通常想要的 - 在这种情况下,您只想从某个顶级服务或服务的调用者调用SaveChanges一次.典型的情况是,单个业务操作在一个事务中有一个工作单元,但您可以在此业务操作中执行大量服务操作.
另一个含义是构建您的存储库.他们可能需要访问数据库,不是吗?所以你可能已经将UoW注入到存储库构造函数中.如果这样做,您可以完全避免UoW与基本服务之间的关系.
归档时间: |
|
查看次数: |
1712 次 |
最近记录: |