Skip to content

Latest commit

 

History

History
50 lines (29 loc) · 2.14 KB

design.md

File metadata and controls

50 lines (29 loc) · 2.14 KB

Design

There is a tiered approach to the API.

For SQL:

SqlInstance > SqlDatabase > Connection

For EntityFramework:

SqlInstance > SqlDatabase > EfContext

SqlInstance represents a SQL Sever instance (in this case hosted in SqlLocalDB) and SqlDatabase represents a SQL Sever Database running inside that SqlInstance.

From a API perspective:

For SQL:

SqlInstance > SqlDatabase > SqlConnection

For EntityFramework:

SqlInstance<TDbContext> > SqlDatabase<TDbContext> > TDbContext/SqlConnection

Multiple SqlDatabases can exist inside each SqlInstance. Multiple DbContexts/SqlConnections can be created to talk to a SqlDatabase.

On the file system, each SqlInstance has corresponding directory and each SqlDatabase has a uniquely named mdf file within that directory.

When a SqlInstance is defined, a template database is created. All subsequent SqlDatabases created from that SqlInstance will be based on this template. The template allows schema and data to be created once, instead of every time a SqlDatabase is required. This results in improved performance by not requiring to re-create/re-migrate the SqlDatabase schema/data on each use.

The usual approach for consuming the API in a test project is as follows.

  • Single SqlInstance per test project.
  • Single SqlDatabase per test (or instance of a parameterized test).
  • One or more DbContexts/SqlConnections used within a test.

This assumes that there is a schema and data (and DbContext in the EntityFramework context) used for all tests. If those caveats are not correct then multiple SqlInstances can be used.

More information: