One question we often receive is if the Apprenda Platform supports the use of ORMs within guest applications. We not only support ORMs but we make it easy for you as developers to configure connections to your databases regardless of where on the platform they end up being deployed. This issue really boils down to one thing: Where do I get my Connection String from?
All ORMs require you to configure or initialize them with the location of your database; this is typically done by specifying the connection information via a Connection String. By allowing the Apprenda platform to manage your database you give up control over where your database is going to be located. The Apprenda platform provides a few different approaches to determining what the Connection String is for your application.
One way to obtain the proper Connection String is to leverage the $#APPLICATIONCONNECTIONSTRING#$ configuration token in your App.config or Web.config which will be replaced during deployment with the actual value. The main drawback to this approach is that it is not dynamic so if you relocate your database your currently deployed workloads will no longer be able to contact your database. Another limitation to this approach is that you cannot leverage the Apprenda platform’s ability to add multi-tenancy to your applications. For these reasons we recommend only using this approach in single-tenant applications on platforms that only have a single database instance exposed to the platform. The main benefit to this approach is it typically requires no actual code changes to an existing application if the application was already retrieving its Connection String from configuration.
The more flexible way of obtaining the correct Connection String is through the API provided TenantContext object. TenantContext.Current.ConnectionString will provide you with a Tenant specific connection string to your database. This approach will support both single and multi-tenant deployments as well as dynamically retrieve the proper Connection String at runtime if you relocate your database. While this is the most flexible approach it does require some code modifications and additional references for your application.
To illustrate the different approaches I will show examples of how to configure both Entity Framework and NHibernate to run on the platform.
You can see here the use of the platform’s ability to perform local / live configuration switching. This allows the developer to develop locally using a locally configured SQL instance while using the Application Connection String token when deployed on the platform.
The Entity Framework implementation in this example is using configuration by convention. The Connection String is being matched up to the defined DbContext by name, in this case TimeCardContext:
The NHibernate example is a little more verbose but results in the same thing:
In both cases the Connection String is being read out of configuration. When not deployed on the platform it will use what is configured locally and when deployed to the platform the local / live switching and token replacement will occur.
If we wanted to change the application to support Multi-tenancy we need to make use of the Apprenda API provided in the SDK. The Entity Framework example above could be modified to support multi-tenancy by simply creating a constructor for TimeCardContext that pulled the Connection String at runtime out of TenantContext.
In much the same way the NHibernate example above can be easily modified to pass in the raw Connection String at runtime.
The Apprenda platform makes using ORMs as part of your application easy and convenient, even in situations where you don’t know where your database will be deployed or if your application will be multi-tenant.
For more information about developing applications for the Apprenda platform visit our Developer Documentation here.