数据层最佳实践

这真的取决于你对世界的看法——我以前是在一个分开的营地里。DAL只是在那里为故事的结尾提供数据。

随着linq-to-sql和实体框架等新兴技术越来越流行,DAL和BAL之间的界限也变得模糊了一些。在L2S中,尤其是DAL与业务对象紧密耦合,因为对象模型对数据库字段有1-1映射。

和软件开发中的任何事情一样,没有正确或错误的答案。你需要了解你的需求和未来的需求,并从那里开始工作。我不会再在达喀尔拉力赛上使用法拉利,就像在赛道上使用路虎揽胜一样。

两者都可以。让数据层不知道您的业务对象,并使其能够处理多种类型的数据源。如果为与数据交互提供公共接口(或抽象类),则可以为每种类型的数据源提供不同的实现。这里的工厂模式很好。

我有一本很好的书,涉及这个话题,是 Data Access Patterns 克利夫顿·诺克。对于如何将业务层与持久性层分离,它有许多很好的解释和想法。你真的应该试试。这是我最喜欢的书之一。

杰弗里·巴勒莫写了一篇关于这个的好文章。他称之为 Onion Architecture .

我发现一个方便的技巧是让我的数据层成为“收集不可知论者”。也就是说,每当我想从我的数据层返回一个对象列表时,我都会让调用者传入该列表。因此,不要这样:

public IList<Foo> GetFoosById(int id) { ... }

我这样做:

public void GetFoosById(IList<Foo> foos, int id) { ... }

如果这是我所需要的,我可以通过一个简单的旧列表,或者如果我计划从UI绑定到它,我可以通过一个更智能的IList<t>(如ObservableCollection<t>)实现。这种技术还允许我从方法中返回一些东西,比如validationresult(如果发生错误,则包含一条错误消息)。

这仍然意味着我的数据层知道我的对象定义,但它给了我一个额外的灵活性。

检查linq to sql,如果我现在正在创建一个新的应用程序,我会考虑完全依赖于一个基于linq的数据层。

除此之外,我认为最好的做法是尽可能地消除数据和逻辑之间的耦合,但这并不总是实际的。逻辑和数据访问之间的纯粹分离使得连接和优化变得困难,这就是Linq如此强大的原因。

在我们使用nhibernate的应用程序中,答案变为“介于两者之间”,而XML映射定义(它们指定哪个表属于哪个对象,哪些列属于哪个字段等)显然在业务对象层中。

它们被传递到通用数据会话管理器,该管理器不知道任何业务对象;唯一的要求是为CRUD传递给它的业务对象必须有一个映射文件。

旧的帖子,但在寻找我遇到的类似信息 this 这解释得很好。