UnitOfWork - 存储库 - 站点答案

【问题标题】：UnitOfWork - IRepository - STEUnitOfWork - 存储库 - 站点
【发布时间】：2013-03-27 07:07:40
【问题描述】：

我正在尝试实现一个简单的 3 层应用程序，组装如下：

1 - DAL（它是一个 UnitOfWork 和 IRepository，带有 POCO 的实体（实体框架 T4））

2 - BLL（参考 DAL）

3 - UI（参考 BLL）

我阅读了很多文章，所以我决定实现一个经典的 UnitOfWork-Repository 模式，其中这些存储库不知道任何自我跟踪实体：

public interface IRepository<T>
{
void Attach(T entity)
{
...
}

问题：如果我的组件将在 winForm 上下文中运行，则某些 UI 控件可能会更改某些实体属性，因此由于内部对象上下文已经在跟踪我的实体，因此作为 Edit(T entity) 进一步调用 Repository 的方法将毫无用处。显然，如果我在 web 上下文中运行一切正常，因为 web 平台是无状态的。一个简单的技巧可以是在每次 BLL 操作后处理我的 objectContext，但我不确定是否要使用此解决方法。所以我正在寻找一个更漂亮的解决方案来管理所有案例。

IRepository 是否应该忽略有关 STE 的任何内容？ BLL 是否应该始终处理自己的内部存储库和/或单元以模拟无状态环境？

【问题讨论】：

标签： entity-framework entity repository-pattern

【解决方案1】：

如果您在 WinForms 中进行开发，为什么要模拟无状态平台？关于 Repository 和 UnitOfWork 模式，不要将它们视为严格绑定到 EntityFramework 的东西。忘记 UI 层中的上下文。这些模式独立于所使用的 ORM，因此您可以轻松切换 DAL 并更有效地测试您的应用程序。

【讨论】：

那么，如何才能实现干净的仓库界面呢？是否应该公开“编辑”方法？
是的，当然。在您的情况下，可能仅调用 Context 中的 Save 方法就足以作为此 Edit 方法的实现（因为无论如何都会跟踪所有内容），但是如果您切换到其他 ORM 或根本没有 ORM 会发生什么？您必须在 Edit 方法中实际实现一些逻辑。