将C＃对象映射到数据库模式
我正在用C＃开发一个客户端 – 服务器桌面应用程序系统 。 客户端只是一个瘦客户端，可以显示服务器告诉它的任何内容。 服务器直接与本地数据库通信，本地数据库用于存储各种系统的元数据。 每个系统都有自己的表，其结构对于该系统是唯一的。
我试图理解如何在没有“硬编码”任何内容的情况下告诉桌面应用程序数据库的结构，如果这是有道理的。 我相信我需要研究对象关系映射，但我不太清楚从哪里开始，因为我以前从未接受过这种复杂性的项目。 我的想法是我的服务器配置以某种方式定义了这个映射，并且它可能是可扩展的，因此我可以在将来为更多系统添加更多映射，或者可能更改映射。
我怎么看这个系统工作是这样的：
客户端上的用户将包含元数据的文件上载到服务器。 服务器将确定此文件所针对的系统类型，然后解析该文件以提取元数据，并将其输入数据库。 我最初设想这种情况的方式是我将有一个通用的抽象类/接口，需要为每个系统类型派生。 然后，派生类将实现特定于该系统类型的解析函数，以便它可以从文件中提取元数据。 但问题是我无法将提取的数据输入数据库，因为服务器不知道派生类的底层结构。
谁能指出我正确的方向？ 我发现了NHibernate ，这听起来像我可能需要的，但我不是百分百肯定。 正如我先前所说，问题的一部分是我对其中一些概念没有充分的理解。 任何人都可以推荐一些在线资源，这些资源可以帮助我理解一般的Object Relational Mapper（ORM） ，特别是它与.Net Framework有什么关系？
这里的最终问题不是使用哪个对象关系映射器（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很可能会让许多开发人员在所有技能级别上都使用代码。 从长远来看，您可以重构数据库模式或模型定义，而不会影响应用程序使用数据对象的方式。
显然需要那些含盐的人，因为测试应用并不意味着它不能进一步测试或变得更好。
您可以找到大量的对象关系映射器：
- 短小精悍的
- NHibernate的
- 开放存取
这些只是大量的可用数量，一个列表链接 。 有些很棒，有些则不是。 最终目标是找到哪一个与您期望的应用目标密切相关 –
希望这真的可以帮到你。
查看OrmLite https://github.com/ServiceStack/ServiceStack.OrmLite
语法非常好，实际上很多来自服务堆栈的东西都很好。
他们还列出了一堆替代品http://www.servicestack.net/benchmarks/