我正在与一位同事“讨论”在新应用程序中实现数据层的最佳方式。
一种观点是数据层应该知道业务对象（我们自己的代表实体的类），并且能够在本地使用该对象。
相反的观点是数据层应该与对象无关，并且纯粹处理简单的数据类型（字符串、布尔值、日期等）。
我可以看到这两种方法都可能有效，但我自己的观点是我更喜欢前者。这样，如果数据存储介质发生变化，业务层就不必（必然）改变以适应新的数据层。因此，从 SQL 数据存储更改为序列化的 xml 文件系统存储将是一件微不足道的事情。
我同事的观点是，数据层不应该知道对象定义，只要数据传递得当，这就足够了。
现在，我知道这是有可能引发一场宗教战争的问题之一，但我希望社区提供任何关于您如何处理此类事情的反馈。
TIA
这真的取决于你对世界的看法——我曾经在非耦合阵营中。DAL 只是为了向 BAL 提供数据——故事的结尾。
随着 Linq to SQL 和实体框架等新兴技术变得越来越流行，DAL 和 BAL 之间的界限变得有些模糊。在 L2S 中，尤其是您的 DAL 与业务对象非常紧密耦合，因为对象模型与您的数据库字段具有 1-1 映射。
就像软件开发中的任何事情一样，没有正确或错误的答案。您需要了解您的要求和未来的要求，并从那里开始工作。我不会再在达喀尔拉力赛上使用法拉利，就像我在赛道日使用路虎揽胜一样。
你可以两者兼得。让数据层不知道您的业务对象，并使其能够处理多种类型的数据源。如果您提供一个通用接口（或抽象类）来与数据交互，那么您可以为每种类型的数据源提供不同的实现。工厂模式在这里很顺利。
我拥有的一本涵盖该主题的优秀书籍是Clifton Nock 的《数据访问模式》。关于如何将业务层与持久层解耦，它有很多很好的解释和很好的想法。你真的应该试一试。这是我最喜欢的书之一。
Jeffrey Palermo 写了一篇关于这个的好文章。他称之为洋葱架构。
我发现方便的一个技巧是让我的数据层“与集合无关”。也就是说，每当我想从我的数据层返回一个对象列表时，我都会让调用者传入列表。所以代替这个：
public IList<Foo> GetFoosById(int id) { ... }
我这样做：
public void GetFoosById(IList<Foo> foos, int id) { ... }
如果这就是我所需要的，这让我可以传入一个普通的旧 List，或者如果我打算从 UI 绑定到它，则可以传入更智能的 IList<T> 实现（如 ObservableCollection<T>）。这种技术还可以让我从方法中返回一些内容，例如 ValidationResult，如果发生错误消息，则包含错误消息。
这仍然意味着我的数据层知道我的对象定义，但它给了我额外的灵活性。
查看 Linq to SQL，如果我现在正在创建一个新应用程序，我会考虑依赖完全基于 Linq 的数据层。
除此之外，我认为尽可能多地分离数据和逻辑是一种很好的做法，但这并不总是可行的。逻辑和数据访问之间的纯粹分离使得连接和优化变得困难，这就是使 Linq 如此强大的原因。
在我们使用 NHibernate 的应用程序中，答案变为“介于两者之间”，因为 XML 映射定义（它们指定哪个表属于哪个对象以及哪些列属于哪个字段等）显然在业务对象层中.
它们被传递给不知道任何业务对象的通用数据会话管理器；唯一的要求是为 CRUD 传递给它的业务对象必须有一个映射文件。
旧帖子但在搜索类似信息时我遇到了这个很好地解释了它。