Domains

A domain is the central place for the connection string and other configuration relating to your project. It is usually defined in a top-level namespace to associate itself with accessors in its child namespaces.

For our project we'll configure the domain to connect to the same SQL Server we generated our database model from. But first, we install the correct support package from one of our supported vendors).

>
dotnet add package Jerrycurl.Vendors.SqlServer

Installing one of these packages enables the easy Use[Database] extension method, which bootstraps the entire vendor process. It not only sets up the connector and connection string, but also injects any vendor specific behavior such as basic SQL syntax, custom type mappings, etc.

The domain definition is simple and requires only implementing a Configure method from the IDomain contract.

1
2
3
4
5
6
7
8
9
10
11
12
namespace Jerrystore
{
    public class JerryDomain : IDomain
    {
        public void Configure(DomainOptions options)
        {
            options.UseSqlServer("SERVER=.;DATABASE=jerrystore;TRUSTED_CONNECTION=true");

            // custom configuration here
        }
    }
}

The lookup strategy from accessors is to look through their parent namespaces for the nearest IDomain implementation and read its configuration from there. This means that you can share or split your accessors into domains connecting to different parts of your database, or to different databases entirely. But in our case a single, top-level domain should be enough.

The domain is also the place where you can place your custom configuration. This could be custom type mappers, additions to the SQL syntax, etc. We provide examples such configuration in our JSON and Entity Framework Core extensions, which we will look at in the next section.