在过去的两年里，我的同事，博客和书籍都教会了一个体面的解决方案的基本项目结构应分为Presentation，Data，Entities作为个别项目。 （更多取决于您对某些事物需要多少层。例如，在某些情况下可能存在过渡层）
但是当我使用Fluent nHibernate时，我发现自己不断在两个不同的Visual Studio项目之间重建相同的目录结构 - 出于什么目的？我被告知这是由于关注点分离的想法，因此可以交换图层......但严重的是，人们是否经常更换整个数据访问层？
是否标准甚至是......在实践中不嘲笑将您的Fluent Mappings捆绑到他们映射到的实体所在的同一个项目中？有什么逻辑上的理由我不应该这样做吗？我在各方面都是新手，非常感谢任何意见。
答案 0 :(得分：1)
虽然人们不经常换掉他们的数据访问层，但这并不是一个很难做到这一点的好理由。如果明年还有另一个更好的ORM，你可以简单地用你的数据访问项目中的新ORM替换你的Fluent NHibernate映射，而不需要对客户端逻辑进行任何更改。实际上，如果您愿意，甚至可以在运行时提供使用任何一个选项。
将数据映射移到域对象之外的另一个原因是促进对象的重用。假设您决定在另一个不需要将它们存储在数据库（如客户端应用程序）中的项目中重用您的域对象（您现在使用Fluent NHibernate映射的对象）。您不希望您的客户端应用程序具有依赖性
答案 1 :(得分：1)
有一点是您并不总是希望或可以公开数据访问（映射）。特别是，通常只有一个组件使用数据访问层，而许多其他组件只使用数据类API，从不知道数据访问。在我当前的项目中，客户端应用程序在一个无法处理NHibernate引用的环境中运行，这使得无法访问数据。但客户端 使用数据类。在另一个项目中，我的（自动生成的）数据类被用于多种编程语言和平台。无论使用何种平台，始终将它们放在单独的模块/程序集/项目/中，以获得一致的API要更加一致。只有服务器正在使用数据访问。
其次，尽可能多地分离独立的东西总是更好，原因很多我懒得提及。
另外，根据我的经验，交换数据访问层并不罕见。
顺便说一下，为什么要将实体与数据类分开是一件令人讨厌的事情？是的，使用今天仍然不完美的编程工具，你会发现自己一遍又一遍地重复相同的实践（希望不会重复代码），但这是有充分理由的。