Is it possible NOT to use data annotations attributes ServiceStack OrmLite?

Question

I'm trying to explore the functionality of ServiceStack.OrmLite and can't understand if it possible to use bootstrap class for configuration (foreign keys, data types, column indexes, aliases etc.)? I don't wanna use data annotation attributes on my entity classes. Even usage of some sort of config's would be better than attributes. That is because i wanna have the chance to replace the ORM in future. Maybe exists third-party lib for fluent configuration?

Answer 1

There is no fluent mapping for ServiceStack.OrmLite. I share your reluctance to refer even the DataAnnotations assembly from my Model definitions. I like my POCO's clean as in entirely clean: separate in their own assembly, not referencing any 3rd party assemblies. It's not as much aesthetics as it's a ways of twisting my arm to avoid temptations to do short-hand stuff that breaks good design. I'm like - if it's not a clean ORM, it's just a tightly coupled DAL, and then it's all for nothing anyway.

Anyway - you can definately annotate your POCO classes in a bootstrapping/impl. kind of place - it's really quite obvious: use reflection and add the attribute at runtime, e.g.

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

Same principle of any attribute of OrmLite (and any attribute, really).

I found the hint in the Unit-tests for OrmLite, there's actually a Can_add_AutoIncrement_Id_at_runtime() unit test. Even though this is essentially unit-testing .NET core and not really OrmLite. Thanks, thourough tester-guy, anyway.

Answer 2

ServiceStack OrmLite creates schemas based on code-first POCOs. Adding attributes are a convenience to alter the sql generated table schema if you wanted OrmLite to create the tables for you. If you don't want to use attributes then manually create the SQL Schema in your database out-of-band, or after the tables are created remove the attributes.

Or use another ORM, OrmLite will never support mappings stored in runtime configuration files - which is against it's code-first philosophy.