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