是否有可能不使用数据注释属性ServiceStack OrmLite？

我想探索ServiceStack.OrmLite的功能，并且无法理解是否可以使用引导类进行配置（外键，数据类型，列索引，别名等）？我不想在我的实体类上使用数据注释属性。即使使用某种配置会比属性更好。那是因为我想有机会在未来取代ORM。也许存在流利配置的第三方库？是否有可能不使用数据注释属性ServiceStack OrmLite？

来源

2013-06-23 user2452329

ServiceStack OrmLite基于代码优先的POCO创建模式。如果您希望OrmLite为您创建表格，添加属性可以方便地更改sql生成的表格模式。如果您不想使用属性，请在数据库带外手动创建SQL架构，或在创建表后删除属性。

或者使用另一个ORM，OrmLite永远不会支持存储在运行时配置文件中的映射 - 这违背了它的代码优先的哲学。

来源

2013-06-23 20:00:13 mythz

谢谢！在我看来，我开始意识到ServiceStack OrmLite的主要概念。但是，如果有一个流畅的API（如NHibernate或EF）来帮助配置SQL模式不是很好吗？正如我所看到的那样，这个ORM没有配置API，并且也没有计划过。 – user2452329

它没有任何价值，没有什么能够阻止重复使用属性POCO的，因为它们对于不使用它的fx没有任何影响。同样，只需几个正则表达式就可以删除项目范围内的属性。所有那些实施单独配置源的努力实际上并没有创造额外的价值，它只是为了安抚一些开发者的审美偏好 - 如果你的目标是保持干净和精益的代码库，这不是一个好策略。 – mythz

我不能完全同意上一条语句，因为如果将模型放置到单独的程序集中，那么必须引用orm程序集，并且需要与它一起部署。但是，尽管如此，我很欣赏你关于干净和精益代码库的观点。 – user2452329

ServiceStack.OrmLite没有流畅的映射。我分享你不愿意参考我的模型定义中的DataAnnotations程序集。我喜欢我的POCO干净整洁：在他们自己的装配中分开，不参考任何第三方装配。这不是美学，因为它是扭动我的手臂的方式，以避免诱惑做短期的东西，打破良好的设计。我喜欢 - 如果它不是一个干净的ORM，它只是一个紧密耦合的DAL，然后它无论如何都是无所事事。

无论如何 - 您可以在bootstrapping/impl中明确注释您的POCO类。种类的地方 - 这真的很明显：使用反射并在运行时添加属性，例如

typeof (User).GetProperty("Id") 
    .AddAttributes(new AutoIncrementAttribute());

OrmLite（和任何属性，真的）的任何属性的原理相同。

我在OrmLite的单元测试中发现了提示，实际上有一个Can_add_AutoIncrement_Id_at_runtime()单元测试。尽管这基本上是单元测试的.NET核心，而不是OrmLite。谢谢，无论如何，你都应该是测试人员。

来源

2013-12-09 01:22:55

是否有可能不使用数据注释属性ServiceStack OrmLite？

回答

相关问题