我正与同事讨论在新应用程序中实现数据层的最佳方式。数据层最佳实践
一个观点是数据层应该知道业务对象（我们自己的代表实体的类），并且能够本身处理这个对象。
相对的观点是数据层应该是对象无关，纯粹和简单处理的数据类型（字符串，布尔变量，日期等）
我可以看到，这两种方法可能是有效的，但我的自己的观点是我更喜欢前者。这样，如果数据存储介质发生变化，业务层不必（必然）不得不改变以适应新的数据层。因此，从SQL数据存储转换到序列化的xml文件系统存储是一件微不足道的事情。
我的同事的观点是，数据层不应该知道对象定义，只要数据被恰当地传递，就足够了。
现在，我知道这是有可能发起宗教战争的问题之一，但我很感谢来自社区的关于如何处理这些事情的任何反馈。
TIA
这真的取决于你对世界的看法 - 我曾经是在非联合阵营。 DAL只在那里向BAL提供数据 - 故事结束。随着Linq to SQL和Entity Framework等新兴技术越来越流行，DAL和BAL之间的界限已经模糊了一些。在L2S中，尤其是您的DAL与业务对象紧密耦合，因为对象模型与您的数据库字段具有1-1映射关系。
与软件开发中的任何事情一样，没有正确或错误的答案。您需要了解您的要求和未来要求，并从那里开展工作。我不会在达喀尔拉力赛上使用法拉利，因为我会在赛道上驾驶揽胜。
一个很好的书我都有，涵盖这个话题，是Data Access Patterns，克利夫顿诺克。它已经得到了很多关于如何将业务层与持久层分离的很好的解释和好点子。你真的应该试试看。这是我最喜欢的书之一。
我发现得心应手的一招是将我的数据层设置为“不可知的集合”。也就是说，无论何时我想从我的数据层返回一个对象列表，我都会让调用者通过列表。因此，而不是这样的：
public IList<Foo> GetFoosById(int id) { ... }
我这样做：
public void GetFoosById(IList<Foo> foos, int id) { ... }
这让我传递一个普通的老名单，如果这就是我所需要的，或者更智能的实现IList的<牛逼>（像ObservableCollection <T>）如果我打算从UI绑定到它。这种技术还可以让我从方法返回东西，比如包含错误消息的ValidationResult（如果发生的话）。
这仍然意味着我的数据层知道我的对象定义，但它给了我一个额外的灵活性。
查看Linq to SQL，如果我现在正在创建一个新的应用程序，我会考虑依赖完全基于Linq的数据层。
除此之外，我认为尽可能地去耦合数据和逻辑是一种很好的做法，但这并不总是实用的。逻辑和数据访问之间的纯粹分离使连接和优化变得困难，这正是Linq如此强大的原因。
你可以拥有两者。让数据层不知道您的业务对象，并使其能够处理多种类型的数据源。如果您提供用于与数据交互的通用接口（或抽象类），则可以为每种类型的数据源提供不同的实现。工厂模式在这里很好。
Jeffrey Palermo写了一篇关于此的好文章。他称之为Onion Architecture。
在我们使用NHibernate的应用程序中，答案变成了“介于两者之间”，因为XML映射定义（它们指定哪个表属于哪个对象以及哪些列属于哪个字段等）显然在业务对象层。
它们被传递给通用数据会话管理器，该管理器不知道任何业务对象;唯一的要求是传递给CRUD的业务对象必须具有映射文件。
旧的帖子，但寻找类似的信息我碰到this这很好地解释它。
我完全同意。数据访问层等的设计变得相当模糊。而我会一直选择将业务逻辑与表示层分开。 MVC模式FTW ;-) – 2012-08-26 17:58:21