它们是一样的吗?刚看完Rob Connery 的店面教程,它们似乎是相似的技术。我的意思是,当我实现一个 DAL 对象时,我有 GetStuff、Add/Delete 等方法,并且我总是先编写接口,以便以后可以切换数据库。
我在混淆事情吗?
它们是一样的吗?刚看完Rob Connery 的店面教程,它们似乎是相似的技术。我的意思是,当我实现一个 DAL 对象时,我有 GetStuff、Add/Delete 等方法,并且我总是先编写接口,以便以后可以切换数据库。
我在混淆事情吗?
你绝对不是那个混淆事物的人。:-)
我认为这个问题的答案取决于你想成为多少纯粹主义者。
如果您想要一个严格的 DDD 观点,那将带您走上一条路。如果您将存储库视为一种模式,它帮助我们标准化了分离服务和数据库的层的接口,它会让您失望。
从我的角度来看,存储库只是一个明确指定的数据访问层。或者换句话说,一种实现数据访问层的标准化方式。不同的存储库实现之间存在一些差异,但概念是相同的。
有些人会对存储库施加更多的 DDD 约束,而另一些人会将存储库用作数据库和服务层之间的便捷中介。像 DAL 这样的存储库将服务层与数据访问细节隔离开来。
似乎使它们不同的一个实现问题是,通常使用采用规范的方法创建存储库。存储库将返回满足该规范的数据。我见过的大多数传统 DAL 将具有一组更大的方法,其中该方法将采用任意数量的参数。虽然这听起来可能是一个很小的差异,但当您进入 Linq 和 Expressions 领域时,这是一个大问题。我们的默认存储库界面如下所示:
public interface IRepository : IDisposable
{
T[] GetAll<T>();
T[] GetAll<T>(Expression<Func<T, bool>> filter);
T GetSingle<T>(Expression<Func<T, bool>> filter);
T GetSingle<T>(Expression<Func<T, bool>> filter, List<Expression<Func<T, object>>> subSelectors);
void Delete<T>(T entity);
void Add<T>(T entity);
int SaveChanges();
DbTransaction BeginTransaction();
}
这是 DAL 还是存储库?在这种情况下,我猜两者兼而有之。
金
存储库是一种可以以多种不同方式应用的模式,而数据访问层有一个非常明确的职责:DAL 必须知道如何连接到您的数据存储以执行 CRUD 操作。
存储库可以是 DAL,但它也可以位于 DAL 前面并充当业务对象层和数据层之间的桥梁。使用哪种实现将因项目而异。
一个很大的区别是,DAO 是一种处理域中任何实体的持久性的通用方法。另一方面,存储库仅处理聚合根。
我正在寻找类似问题的答案,并同意排名最高的两个答案。试图为自己澄清这一点,我发现如果与存储库模式齐头并进的规范被实现为域模型的一等成员,那么我可以
我什至可以说,除非存储库模式与规范模式一起使用,否则它不是真正的“存储库”,而是一个 DAL。伪代码中的一个人为示例:
specification100 = new AccountHasMoreOrdersThan(100)
specification200 = new AccountHasMoreOrdersThan(200)
assert that specification200.isSpecialCaseOf(specification100)
specificationAge = new AccountIsOlderThan('2000-01-01')
combinedSpec = new CompositeSpecification(
SpecificationOperator.And, specification200, specificationAge)
for each account in Repository<Account>.GetAllSatisfying(combinedSpec)
assert that account.Created < '2000-01-01'
assert that account.Orders.Count > 200
有关详细信息,请参阅Fowler 的规范论文(这就是我上面的内容)。
DAL 将具有专门的方法,例如
IoCManager.InstanceFor<IAccountDAO>()
.GetAccountsWithAtLeastOrdersAndCreatedBefore(200, '2000-01-01')
您可以看到这很快就会变得很麻烦,尤其是因为您必须使用这种方法定义每个 DAL/DAO 接口并实现 DAL 查询方法。
在 .NET 中,LINQ 查询可以是实现规范的一种方式,但组合规范(表达式)可能不像使用本土解决方案那样顺畅。这个 SO Question中描述了一些想法。
我个人的看法是,这都是关于映射的,请参阅: http: //www.martinfowler.com/eaaCatalog/repository.html。所以存储库的输出/输入是域对象,在 DAL 上可以是任何东西。对我来说,这是一个重要的添加/限制,因为您可以为数据库/服务/任何具有不同布局的内容添加存储库实现,并且您有一个明确的位置可以专注于进行映射。如果您不使用该限制并在其他地方进行映射,那么使用不同的方式来表示数据可能会影响不应更改的地方的代码。
这都是关于解释和上下文的。它们可能非常相似,也可能确实非常不同,但只要解决方案能胜任,名字里有什么!
存储库是一种模式,这是一种以标准化方式实现事物以尽可能重用代码的方法。
使用存储库模式的优点是模拟您的数据访问层,这样您就可以在不调用 DAL 代码的情况下测试您的业务层代码。还有其他很大的优势,但这对我来说似乎非常重要。
在外部世界(即客户端代码)存储库与 DAL 相同,除了:
(1) 它的插入/更新/删除方法被限制为以数据容器对象作为参数。
(2) 对于读取操作,可能需要简单的规范,如 DAL(例如 GetByPK)或高级规范。
在内部,它与数据映射层(例如实体框架上下文等)一起工作以执行实际的 CRUD 操作。
什么存储库模式并不意味着:-
此外,我看到人们经常感到困惑,除了将插入/更新/删除方法执行的所有内存更改提交到数据库的插入/更新/删除方法之外,还有一个单独的保存方法作为存储库模式示例实现。我们可以在存储库中肯定有一个 Save 方法,但这不是存储库的责任来隔离内存中 CUD(创建、更新、删除)和持久性方法(在数据库中执行实际的写入/更改操作),但是工作单元模式的责任。
希望这可以帮助!
据我了解,它们的含义基本相同——但命名因上下文而异。
例如,您可能有一个实现 IRepository 接口的 Dal/Dao 类。
Dal/Dao 是数据层术语;应用程序的更高层考虑存储库。
那么在大多数(简单)情况下,DAO 是存储库的实现吗?
据我了解,DAO 似乎精确地处理数据库访问(CRUD - 虽然没有选择?!),而 Repository 允许您抽象整个数据访问,也许是多个 DAO(可能是不同的数据源)的外观。
我在正确的道路上吗?
有人可能会争辩说,“存储库”是一个特定的类,而“DAL”是由存储库、DTO、实用程序类和其他任何所需的东西组成的整个层。