Notion of CQRS

[jaredcnance]

It should be straightforward to implement query only endpoints without having to implement all members of IResourceService or IEntityRepository and throwing NotImplementedExceptions. This issue is a placeholder until I can work out the design.

Until final release, there are no guarantees on non-breaking changes in pre-release versions

2017-6-11

This work is going to be done on feat/cqrs branch and available as pre-release v2.1.0-alpha1-*

2017-6-30

The current version is available on the unstable branch and can be installed from this MyGet feed. If everything goes well, I plan on wrapping up tests this weekend and pushing to NuGet as a beta.

[jaredcnance]

I think the above proposal is okay, but it still means that some services may end up having NotImplementedExceptions. The only way I see around this, is to fully segregate the service interfaces by method.

One way to do this is to continue the preceding pattern, but push it into the resource service layer:

protected ResourceService(
    IGetAllService<T, TId> getAll,
    IGetByIdService<T, TId> getById,
    IGetRelationshipsService<T, TId> getRelationships,
    IGetRelationshipService<T, TId> getRelationship,
    ICreateService<T, TId> create,
    IUpdateService<T, TId> update,
    IUpdateRelationshipService<T, TId> updateRelationship,
    IDeleteService<T, TId> delete)
{
    _getAll = getAll;
    _getById = getById;
    _getRelationships = getRelationships;
    _getRelationship = getRelationship;
    _create = create;
    _update = update;
    _updateRelationship = updateRelationship;
    _delete = delete;
}

// ... 

Then the controller constructor would receive enums stating what methods are allowed:

protected BaseJsonApiController(
    IJsonApiContext jsonApiContext,
    IResourceService<T, TId> resourceService,
    Endpoints endpoints)
{
    // ...
}

public virtual async Task<IActionResult> GetAsync()
{
    if (_endpoints.HasFlag(Endpoints.Get) == false) 
        throw new JsonApiException(405, "Request is not supported");

    var entities = await _resourceService.GetAsync();

    return Ok(entities);
}

// ...

EntityResourceService will need to be the entity that accepts the above interfaces.

Usage

public class MyReportsController : BaseJsonApiController<MyReport>
{
    public MyReportsController(
        IJsonApiContext jsonApiContext, 
        IResourceService<MyReport> resourceService) 
        : base(jsonApiContext, resourceService, Endpoints.Get | Endpoints.GetById)
    { }

    [HttpGet]
    public override async Task<IActionResult> GetAsync() => await base.GetAsync();
}

And then the custom service would look like:

public class MyReportService : IGetAllService<MyReport>
{
    private readonly IJsonApiContext _jsonApiContext;
    private readonly AppDbContext _dbContext;

    public MyReportService(
        IJsonApiContext jsonApiContext,
        AppDbContext dbContext)
    {
        _jsonApiContext = jsonApiContext;
        _dbContext = dbContext;
    }
    
    public async Task<IEnumerable<MyReport>> GetAsync()
        => _dbContext.MyReports; // --- some ad hoc query --- //
}

[williamwong]

I like the idea of the proposal overall, but two questions:

1. In general, my service layer doesn't interact with Entity Framework at all. I interact with the entities using just the IEntityRepository interface. Is there a way to implement the custom service as you've described above without "leaking" the DbContext into the service layer?
2. What's the advantage of having the endpoints enum rather than using C# attributes on the controller, which seems to be the general convention for describing which HTTP methods are supported?

[jasolko]

@williamwong it looks to me like the DbContext is being used specifically in the example implementation of the MyReportService and isn't required by any base class. Any concrete implementation would be able to define its own dependencies.

I also wonder what the reason is for the endpoint enums over using attributes on the controller?

With the interfaces segregated this way and by defining what methods are supported on the controller is there still a reason to also have separate Cmd/Query Controller/Services?

[jaredcnance]

@jasolko that's correct.

What's the advantage of having the endpoints enum rather than using C# attributes on the controller, which seems to be the general convention for describing which HTTP methods are supported?

I also wonder what the reason is for the endpoint enums over using attributes on the controller?

The enums were chosen for simplicity of implementation and to reduce reflection. But, I am wondering if that is even needed. Technically, this means the available endpoints have been defined twice, once in the resource controller and then again in the base class constructor. This is probably not necessary.

With the interfaces segregated this way and by defining what methods are supported on the controller is there still a reason to also have separate Cmd/Query Controller/Services?

I'm not certain. From the controller standpoint, it would be a quick way to implement it without having to explicitly define the method signatures yourself and that is the only advantage I see.

Regarding the services, these interfaces would just allow for fewer parameters in the constructors (for scenarios that require all query endpoints or all cmd endpoints). But, this is something we can iterate on, so maybe start with fewer implementation options and improve as needed.

Overall, I'm not super happy with this direction yet. So, any proposals are more than welcome. I'm hoping I can get this flushed out within the next 2 weeks.

[jaredcnance]

I have a working example of this on the unstable branch here.

From an implementation perspective, I think this is okay. Your service simply implements the interfaces you need and you pass the specific service to the base constructor in your controller.

[williamwong]

If your service implements more than one of the interfaces, what do you pass into controller?

I see that you've got a whole hierarchy of interface inheritance, so I guess the intention is that that should cover most reasonable permutations of create/update/get/delete, so you would choose IGetAllService, IResourceCmdService, or IResourceService, etc. as needed, right? And your service should rarely implement more than one of the interfaces?

[jaredcnance]

@williamwong if your service is implementing multiple interfaces, but not enough to fully implement IResourceCmdService or IResourceQueryService, you first need to inject the service for each implemented interface. Using Autofac, as an example, this is simply:

public class MyResourceService : ICreateService<MyResource>, IDeleteService<MyResource> {
 //...
}

public class Startup {
  public IServiceProvider ConfigureServices(IServiceCollection services) {
    // ...
    builder.RegisterType<MyResourceService>().AsImplementedInterfaces();
    // ...
  }
}

Then in your controller:

public class MyResourcesController : BaseJsonApiController<MyResource, int> {
    public MyResourcesController(
        IJsonApiContext jsonApiContext, 
        ICreateService<MyResource> create,
        IDeleteService<MyResource> delete) 
    : base(
        jsonApiContext, 
        create: create, // <--- pass the services to the base controller using named optional parameters
        delete: delete) { }

    [HttpPost]
    public override async Task<IActionResult> PostAsync([FromBody] MyResource entity) 
        => await base.PostAsync(entity);

    [HttpDelete("{id}")]
    public override async Task<IActionResult>DeleteAsync(int id) 
        => await base.DeleteAsync(id);
}

I haven't compiled the above code, so please pardon errors

[williamwong]

Thanks for the explanation @jaredcnance . This looks great!