title: Using ADO.NET for a Data Access Layer in ASP.NET Core
body: <p>I'm trying to roll a high performance DAL for my ASP.NET Core API. I want to use ADO.NET and I am having difficulty designing the software architecture. I'm looking for help discussing a good approach.</p>
  
  <h2>What I Have</h2>
  
  <p>My codebase will consist of three projects</p>
  
  <ul>
  <li>MyApp.API</li>
  <li>MyApp.Repositories (data access layer)</li>
  <li>MyApp.Services (business logic)</li>
  </ul>
  
  <p>I'll implement <code>IUnitOfWork</code> within <code>MyApp.Repositories</code> and create a concrete <code>SqlUnitOfWork</code> in <code>MyApp.API</code>. <code>Startup.cs</code> will register <code>IUnitOfWork</code> to <code>SqlUnitOfWork</code>. Later on, when I get more data sources (Mongo, etc.), I can incorporate a <code>UnitOfWorkFactory</code>. </p>
  
  <h2>Questions</h2>
  
  <ol>
  <li><p>Should I register each repository in <code>Startup.cs</code> or simply add them as properties of <code>IUnitOfWork</code>? The thinking here is I would use Dependency Injection in my Controllers, Services and Repositories, but only have to inject <code>IUnitOfWork</code>.</p></li>
  <li><p>How do I pass my connection string into the <code>SqlUnitOfWork</code>? I know the connection string should stay within <code>MyApp.API</code>.</p></li>
  </ol>