这里的最终问题不是要使用哪个对象关系映射器（ORM），而是这样的映射器最终会做什么。这个特定的层经常交织到数据访问层 (DAL)中。
您会看到这里的函数本质上是一种在不兼容类型之间进行转换的技术。本质上，它创建了一个可以使用的虚拟对象数据库。该层的重要性是将您的域逻辑/业务层链接到您的数据访问层或对象关系映射器。这本质上有助于解耦不需要访问数据结构的逻辑——这使得用户界面、域逻辑和数据访问层之间的解耦更加连贯。
接口不知道您的数据层如何与您的数据结构对话。目前，由于相似之处，我一直在混合数据访问层和对象关系映射器，但它们完全不同。
数据访问层与对象关系映射器有何不同
与面向对象语言和关系数据库之间的传统交换技术相比，对象关系映射器通常会减少需要编写的代码量。这种好处是显而易见的——但也包含一个巨大的陷阱。他们倾向于过度抽象正在发生的事情，这掩盖了实际发生的事情。
要考虑的另一件事是，如果您过度依赖ORM，它可能会产生设计不佳的数据库。
从图中可以看出，这就是Object Relational Mapper背后的理论。在N 层体系结构或面向服务的体系结构中经常发现的数据访问层。
两者的主要区别在于：
对象关系映射工具以这种方式提供数据层，遵循活动记录模型。ORM/活动记录模型在 Web 框架中很流行。
数据访问层是简化对存储在某种持久存储中的数据的访问的层。使用数据访问层的应用程序可以依赖于数据库服务器，也可以独立于数据库服务器。如果数据访问层支持多种数据库类型，应用程序就可以使用 DAL 可以与之通信的任何数据库。在任何一种情况下，拥有一个数据访问层都为对数据库的所有调用提供了一个集中位置，因此可以更轻松地将应用程序移植到其他数据库系统（假设 100% 的数据库交互在 DAL 中完成）应用）。
正如您现在可以看到的相似之处和不同之处，但是数据结构呢？我是否被迫在数据库中？简短的回答是否定的。您有以下一些选择：
- 关系数据：您将使用更传统的数据库方法。
- NoSQL：对象关系映射器* 遵循NoSQL方法出现。
这将根据您的项目要求提供更大的灵活性。Stack Overflow上的一个很好的问题实际上有一个使用NoSQL方法的现实世界。（这里）
四个非常明显的好处是：
生产力：数据访问代码通常是典型应用程序的重要部分，编写该代码所需的时间可能是整个开发计划的重要部分。使用 ORM 工具时，代码量不太可能减少——事实上，它甚至可能会增加——但 ORM 工具会根据您定义的数据模型，在瞬间自动生成 100% 的数据访问代码。
应用程序设计：由经验丰富的软件架构师设计的优秀 ORM 工具将实现有效的设计模式，几乎迫使您在应用程序中使用良好的编程实践。这有助于支持关注点的清晰分离和允许并行、同时开发应用程序层的独立开发。
代码重用：如果您创建一个类库来为 ORM 生成的数据访问代码生成单独的 DLL，您可以轻松地在各种应用程序中重用数据对象。这样，每个使用类库的应用程序根本不需要数据访问代码。
应用程序可维护性： ORM 生成的所有代码都可能经过良好测试，因此您通常无需担心对其进行广泛测试。显然，您需要确保代码能够满足您的需求，但广泛使用的 ORM 可能会让许多不同技能水平的开发人员对代码进行攻击。从长远来看，您可以重构数据库架构或模型定义，而不会影响应用程序使用数据对象的方式。
显然，拿一粒盐来说，因为一个应用程序经过测试并不意味着它不能被进一步测试或变得更好。
您可以找到大量对象关系映射器：
这些只是可用的大量数量中的一小部分，带有列表的链接。有些很棒，有些则不然。 最终目标将是找到哪个与您期望的应用目标密切相关-
希望这真的可以帮助你。