我是 Service Stack 和 OrmLite 的新手,并且正在探索 ORMLite 作为 Entity Framework 的替代方案。我对此有 2 个问题: - EF 吸引我的原因是能够将数据库操作和业务数据模型分离到单独的层中 - EF 可以使用您在配置文件的连接字符串中指定的任何内容运行。ORMLite 似乎对不同的数据库有不同的风格,这让我很担心,因为我不想重复进行代码更改。
我理解正确吗?请澄清
谢谢
苏拉杰
我是 Service Stack 和 OrmLite 的新手,并且正在探索 ORMLite 作为 Entity Framework 的替代方案。我对此有 2 个问题: - EF 吸引我的原因是能够将数据库操作和业务数据模型分离到单独的层中 - EF 可以使用您在配置文件的连接字符串中指定的任何内容运行。ORMLite 似乎对不同的数据库有不同的风格,这让我很担心,因为我不想重复进行代码更改。
我理解正确吗?请澄清
谢谢
苏拉杰
OrmLite 通过使用DialectProvider 的.
基本上,只要某些 RDBMS 偏离规范并需要特别注意,此功能就会被分解到方言提供程序中,因此它可以提供定制功能并覆盖默认行为。
过去曾在 ORM 上工作过,我可以告诉您 ORM 实际上并不是“与数据库无关”。相反,ORM 试图尽可能地与数据库无关,并且通常有一个目标集。如果您帮助添加对不在列表中的数据库的支持,他们当然会喜欢您。
例如,ORM 不太可能支持 NoSQL 数据库(例如 Redis、CouchDB)[但并非不可能]、原生 XML(例如 eXist)或面向对象的数据库(例如 Zope)。在大多数情况下,这些技术以 RDBMS 为目标,而且它们通常做得很好。
由于这是基于 Java 构建的,因此您可能会有很多选择 - 任何与 JDBC 连接的东西都可能会受到支持,或者保留扩展的可能性。
在这些工具的核心,您编写的 SQL 和函数会被底层数据库解析和消化。理论上可以使用任何数据库。
StingyJack 找到了支持的确切数据库。MySQL、Postgres、Microsoft SQL Server、H2、Derby、HSQLDB 和 Sqlite。
现在请记住,另一个特性是新数据库通常可以通过使用代码中的接口来支持 - 因此,如果您没有看到您想要的数据库,您可能会复制另一个模块并对其进行修改,直到它符合要求。
因为这些工具是按照标准模式构建的,所以该模式被重新应用并适用于每个数据库。因此,随着该列表的增长,您应该能够安全地期望每个新数据库都获得相同的支持。
话虽如此,观察任何开源项目的活动是个好主意,因为如果在达到成熟状态之前未充分利用或承诺不足,支持可能会落后。
这个特殊的 ORM 似乎是基于 SQL 的,所以不要期望扩展的支持涵盖非关系数据库。