In order to support different database servers you will have to use our code-only mapping as you are already doing. This documentation article
provides more information on how to implement a switching mechanism for the database servers you need to support and also lists some points you will need to consider when building your fluent mapping model. If you are not planing to switch between database server during runtime you could just change the connection in your configuration file.
On the matter of the multiple models, our general recommendation in such cases would be to use a single model. Although a valid approach, using multiple models could lead to higher memory usage and possibly synchronization issues is some situations. For those reason the multiple models approach is not suitable for logical separation of the database. If you have any additional consideration that could benefit from multiple models, please let us know so we could advice you better.
As an alternative, in order to separate your code logically, I would recommend you to group the fluent mapping code in separate files as dictated by you database schema. Each file will contain the mapping for specific tables. Then all those mappings could be used to create a new FluentMetadataSource
that combines them. The resulting FluentMatadataSource
could be used by the OpenAccessContext
class. This way the database mapping will still be separated into logical categories in your code but you will avoid any overhead that would not be required in your scenario.
Should you have any further question or need any further assistance, please let us know.
OpenAccess ORM is now Telerik Data Access
. For more information on the new names, please, check out the Telerik Product Map