Skip to content

Providers and Plugins

The service types in the domain layer do not have hard-wired dependencies on any 3rd party technologies. Instead, these service types define and work with abstractions in the form of interfaces and abstract base classes. For example, the MapService is depending on an object implementing the IMapSource interface. At run-time, such a service will need a concrete object implementing this interface – but will work with any implementation:

Such abstractions act as seams between the pure and stable domain layer and the more volatile and technology-specific details.

The concrete implementations of these interfaces are called plugins. The typical plugin is technology-specific – i.e. depending on a specific technology. Hence, the plugins very often act as adapters between the domain layer services and specific technologies.

All technology-specific plugins are gathered in their own component (their own assembly/DLL). Such components are called providers. The namespace convention for providers is as follows:

DHI.Services.Provider.{technology}

For example, all the plugins for the MIKE Software file formats are gathered in a component called DHI.Services.Provider.MIKECore. Here is an illustration of just a few examples of the plugins from the MIKE Core provider:

  • Various time series repositories for different dfs-files
  • A feature repository serving vector graphics (features) from a dfsu-file for the GIS service
  • A map source serving bitmap images from a dfsu files for the Map service

Like all other Domain Services components, also providers are published as NuGet packages.

Generally, the naming convention for NuGet packages is that the NuGet package name is equivalent to the name of the contained assembly/DLL. However, there is a subtle exception for providers, where the “Provider”-part of the namespace is left out from the package name. Hence, the component DHI.Services.Provider.MIKECore.dll is published in a package called DHI.Services.MIKECore.