将C＃对象映射到数据库模式

Question

我正在 C＃中开发客户端 - 服务器桌面应用程序系统。 客户端只是一个瘦客户端，可以显示服务器告诉它的任何内容。 服务器直接与本地数据库通信，本地数据库用于存储各种系统的元数据。每个系统都有自己的表，其结构对于该系统是唯一的。

我试图理解如何在没有“硬编码”任何内容的情况下告诉桌面应用程序数据库的结构，如果这是有道理的。我相信我需要调查Object-relational mapping，但我不太清楚从哪里开始，因为我以前从未接受过这种复杂性的项目。我的想法是我的服务器配置以某种方式定义了这个映射，并且它可能是可扩展的，因此我可以在将来为更多系统添加更多映射，或者可能更改映射。

我如何看待这个系统是这样的：

  

客户端上的用户将包含元数据的文件上传到   服务器。服务器将确定此文件所属的系统类型   for，然后解析文件以提取元数据，并将其输入   数据库。我最初设想这种情况的方式是   我会有一个需要的通用抽象类/接口   为每种系统类型派生。然后派生类   实现特定于该系统类型的解析函数，以便它可以   从文件中提取元数据。但这里的问题是我   因为，无法将提取的数据输入数据库   服务器不知道派生类的底层结构。

有人能指出我正确的方向吗？我发现了NHibernate，这听起来像我可能需要的那样，但我不是百分百肯定的。 问题的一部分，正如我之前所说，我对其中一些概念没有完全理解。任何人都可以推荐一些可以帮助我理解对象关系映射器的在线资源（ORM）一般来说，具体如何与 .Net Framework 相关？

Answer 1

这里的最终问题不是对象关系映射器（ORM）要使用的，而是最终这样的映射器所做的事情。此特定层通常交错到数据访问层（DAL）。

您会发现此处的函数本质上是一种在不兼容类型之间转换的技术。基本上它创建了一个可以使用的虚拟对象数据库。此层的重要性在于将域逻辑/业务层链接到数据访问层或对象关系映射器。这实际上有助于解耦不需要访问数据结构的逻辑 - 这使得用户界面，域逻辑和数据访问层之间的解耦变得更加连贯。

接口不知道数据层如何与您的数据结构对话。目前我一直在混合数据访问层和对象关系映射器，因为它们有相似之处，但它们完全不同。

数据访问层如何与对象关系映射器不同

与面向对象语言和关系数据库之间的传统交换技术相比，对象关系映射器通常会减少需要编写的代码。这种好处显而易见 - 但包括巨大的陷阱。他们倾向于过度抽象正在发生的事情，这掩盖了实际正在发生的事情。

另外需要考虑的是，如果过度依赖 ORM ，可能会产生设计不佳的数据库。

从图中可以看出，这是对象关系映射器背后的理论。通常在 N层架构或面向服务的架构中找到数据访问层的位置。

两者之间的主要区别是：

  

对象关系映射工具以这种方式提供数据层，   遵循活动记录模型。 ORM /主动记录模型是   受Web框架欢迎。

     

数据访问层是简化数据访问的层   存储在某种持久存储中。使用数据的应用程序   访问层可以是数据库服务器依赖的也可以是独立的   如果数据访问层支持多种数据库类型，则   应用程序变得能够使用DAL可以说的任何数据库   至。在任何一种情况下，拥有数据访问层都可以提供   所有调用进入数据库的集中位置，从而使   将应用程序移植到其他数据库系统更容易（假设   100％的数据库交互是在给定的DAL中完成的   应用程序）。

正如您现在可以看到的相似之处和不同之处，但数据结构如何呢？我被强迫进入数据库吗？简短的回答是否。您有以下选择：

• 关系数据：您将使用更传统的数据库方法。
• NoSQL：对象关系映射器*已经出现，遵循 NoSQL 方法。

这将根据您项目的要求提供更大的灵活性。关于 Stack Overflow 的一个很好的问题实际上是一个带有 NoSQL 方法的真实世界。 (here)

四个非常明显的好处是：

• 生产力：数据访问代码通常是一个重要部分 一个典型的应用程序，以及编写该代码所需的时间 是整个开发计划的重要组成部分。什么时候 使用ORM工具，代码量不太可能降低 事实上，它甚至可能会上升 - 但ORM工具会生成100％的数据 仅仅基于您定义的数据模型自动访问代码 时刻。

• 应用程序设计：由经验丰富的人员设计的优秀ORM工具 软件架构师将实施有效的设计模式 几乎迫使你在应用程序中使用良好的编程实践。 这有助于支持关注和独立的清晰分离 允许并行，同步开发的开发 应用层。

• 代码重用：如果创建类库以生成单独的DLL 对于ORM生成的数据访问代码，您可以轻松地重用数据 各种应用中的对象。这样，每个人 使用类库的应用程序不需要数据访问代码 完全没有。

• 应用程序可维护性： ORM生成的所有代码都是 大概经过充分测试，所以你通常不需要担心 广泛测试。显然你需要确保代码 做你需要的，但广泛使用的ORM可能有代码 被各种技能水平的开发人员所击败。从长远来看， 您可以在不重构数据库模式或模型定义的情况下进行重构 影响应用程序使用数据对象的方式。

显然需要那些含盐的人，因为测试应用程序并不意味着它无法进一步测试或变得更好。

您可以找到对象关系映射器的大型列表：

• Dapper
• NHibernate
• Open Access

这些只是大量的可用数量，link有一个列表。有些很棒，有些则不是。 最终目标是找到哪一个与您期望的应用目标密切相关 -

希望这真的能帮到你。

Answer 2

查看OrmLite https://github.com/ServiceStack/ServiceStack.OrmLite

语法非常好，实际上很多来自服务堆栈的东西都很好。

他们还列出了一堆替代品 http://www.servicestack.net/benchmarks/