RFC: De-Couple data access from EF

Problem

Currently, the controller leans on IEntityRepository directly which is tightly coupled to IQueryable. However, this doesn’t make much sense for ORMs, like Dapper, that do not use IQueryable. Also, it is entirely possible that resources may be retrieved from non SQL storage solutions, such as another HTTP API or RPC.

Tightly Coupled Areas:

• JsonApiController
• ContextGraph
• ContextGraphBuilder
• IServiceCollectionExtensions
• Internal.Generics

Proposed Solution

1. Extract controller logic into IResourceService. Reduces controller methods to something like the following. Would allow any intermediate service to perform the data access.

public class JsonApiController<T, TId>
    : JsonApiControllerMixin where T : class, IIdentifiable<TId>
{
    private readonly IResourceService<T, TId> _service;

    public JsonApiController(IResourceService<T, TId> resourceService)
    {
        _service = resourceService;
    }

    [HttpGet]
    public virtual async Task<IActionResult> GetAsync()
    {
        var entities = await _service.GetAsync();
        return Ok(entities);
    }
}

1. Refactor the context graph:

• Rename ContextGraphBuilder to EntityContextGraphBuilder, since it uses the EF DbContext.
• Can ContextGraph<T> be used without the DbContext generic? If not, perform rename Entity...
• Define API to either inject custom IContextGraph implementations or an API to build a generalized context graph

1. Refactor service extensions or add methods for using the new APIs defined by (2)

Considerations

• Need to take a closer look at json:api operations and how this would fit in.
  • https://github.com/json-api/json-api/issues/795
• Since this may introduce a variety of breaking changes, perhaps we should consider further de-coupling from the MVC middleware in this solution as well (see discussion in #71)?

[JanMattner]

Sounds good. In order to decouple it completely, we must get rid of the DbContext generic type. So rather something like:

services.AddJsonApi(opt => {
  opt.BuildContextGraph(builder => {
     builder.WithDbContext<AppDbContext>();
     builder.WithResource<MyResource>("my-resources");
  });
});

=> Everything inside the DbContext can be added and further more custom ressources not bound to any DbContext. For backwards compatibility, we can still leave the currently public methods as is and call this builder internally.

[donniefitz2]

Been getting familiar with the project and that’s one of the first things that came to mind. Can I use this with a custom business/data layer? That would be really nice.