我正与一位同事"讨论"在新应用程序中实现数据层的最佳方法。

一种观点认为，数据层应了解业务对象(代表实体的我们自己的类)，并能够本机使用该对象。

相反的观点是，数据层应该是对象不可知的，并且仅处理简单的数据类型(字符串，布尔值，日期等)。

我可以看到两种方法都是有效的，但是我个人的观点是我更喜欢前一种方法。这样，如果数据存储介质发生更改，则业务层无需(必须)更改以容纳新的数据层。因此，从SQL数据存储更改为序列化xml文件系统存储将是一件微不足道的事情。

我同事的观点是，数据层不必了解对象定义，只要适当地传递数据就足够了。

现在，我知道这是可能引发宗教战争的那些问题之一，但是我很感谢社区中关于我们如何处理此类问题的任何反馈。

TIA

解决方案

回答

我有一本出色的书涵盖了这个主题，是Clifton Nock撰写的Data Access Patterns。关于如何使业务层与持久层脱钩，它有很多很好的解释和好主意。我们确实应该尝试一下。这是我最喜欢的书之一。

回答

我发现方便的一个窍门是让我的数据层"与集合无关"。也就是说，每当我想从数据层返回对象列表时，都会让调用者传递该列表。所以代替这个：

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如此强大的原因。

回答

你们两个都可以。让数据层不了解业务对象，并使其能够使用多种类型的数据源。如果提供用于与数据进行交互的公共接口(或者抽象类)，则每种数据源类型可以具有不同的实现。工厂模式在这里进展顺利。

回答

Jeffrey Palermo对此写了一篇很好的文章。他称其为洋葱建筑。

回答

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

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

回答

这确实取决于我们对我曾经处于未耦合阵营中的世界的看法。 DAL仅在那里为BAL故事的结尾提供数据。

随着诸如Linq to SQL和Entity Framework之类的新兴技术变得越来越流行，DAL和BAL之间的界限变得模糊了一些。在L2S中，尤其是DAL与业务对象紧密耦合，因为对象模型具有1-1映射到数据库字段。

像软件开发中的任何事物一样，没有正确或者错误的答案。我们需要了解要求和将来的要求，然后从那里开始工作。在赛道日，我将不再像在路虎揽胜上那样在Dakhar集会上使用法拉利。

回答

旧帖子，但在搜索类似信息时，我偶然发现了这一点，这很好地解释了它。