Orm F#类型提供程序会为实现对象关系映射提供良好的基础吗？

从我到目前为止读到的关于类型提供程序的信息来看，我想知道它们是否可以用于为F#实现一个好的ORM

我设想数据库行可以由具有正确类型属性的对象表示，允许对列值进行类型安全读写访问，类型提供程序实现在编译时自动检查当前数据库模式

---

这是一个现实且有用的场景吗？

如果我是正确的，那么类型提供程序将是F#编译器的某种“插件”。他们将插入F#编译器在编译代码时无法找到的类型信息。因此，基本上在编译F#代码时，编译器会要求类型提供程序填写F#编译器不知道的类型信息。这也意味着它仍然是关于静态类型的，即类型是在编译时识别的

如果上述理解是正确的，那么对于ORM，您将需要为关系方案实现一个类型提供程序，F#编译器将使用该类型提供程序来编译代码，以“填充”表示ORM映射的类型

---

如果您看一下ORM，它们不仅仅是关于将关系数据映射到对象，而且还提供了各种操作，如对底层关系数据的查询、更新等。在我看来，目前我认为F#类型提供程序不适合ORM，但我可能错了：）

是的，类型提供程序的使用很有趣。其中一个示例就是这样做的，请参见

是的，我知道类型提供程序不会提供ORM的实际功能。但是我想知道它们是否有助于使ORM静态类型安全，而不使用代码生成。。不是吗？+1个好问题。仍在等待简化和改进ORMs的技术。也许类型提供程序会有所帮助？@Daniel-你曾经使用过Linq到Sql吗？我认为它非常出色（好吧，至少C#实现，F#实现似乎还没有为黄金时间做好准备）。我不喜欢Entity framework/Hibernate重载的各种ORM：我认为关系模型是一种灵活、高效、可查询的存储模型，我无法理解通过预先对象映射（除了用于进一步特殊查询的1对1表映射）过早地将其功能抽象掉的愿望。我觉得最痛苦的是RDBMS实现和SQL，而LINQtoSQL解决了大部分问题。@Stephen:大多数ORM提供（大概是因为大多数开发人员需要）数据的静态表示。我更希望具有动态性（例如，如果我添加一列，ORM应该“拾取它”；我不必重新生成代码）。因此，我没有花太多时间使用LINQtoSQL。使用类似于

System.Dynamic.DynamicObject

的东西来实现我想要的语法行为似乎是微不足道的，但这就留下了更复杂的部分来处理：RDBMS实现细节。@Stephen：（cont.）我喜欢这个问题，因为类型提供程序似乎提供了动态性和类型安全性，因此（在我看来）是实现ORM的完美工具。NuGet上至少有一个类型提供程序（2017年1月）从数据库中实时获取模式。我自己更喜欢通过SqlMetal for Linq2Sql进行静态生成，因为我不希望构建依赖于实时数据库。