Support async methods in the IMaterializer

[csantero]

This is the main reason I am not using JSONAPI.NET's ApiController implementation yet. I have a service layer that has async CRUD methods that I want to await in async WebAPI actions, but the synchronous IMaterializer interface that ApiController<> uses gets in the way.

I propose converting the interface to the following:

Task<T> GetById<T>(params Object[] keyValues);
Task<object> GetById(Type type, params Object[] keyValues);
Task<T> Materialize<T>(T ephemeral);
Task<object> Materialize(Type type, object ephemeral);
Task<T> MaterializeUpdate<T>(T ephemeral);
Task<object> MaterializeUpdate(Type type, object ephemeral);

I think this is better than supporting both sync and async versions of each method, since you can easily wrap a synchronous method result in a Task.FromResult(), if you really need to.

[SphtKr]

Not opposed to the API change...we might want to provide a subclass shim (marked [Obsolete]) that does that Task.FromResult() and presents the old method signatures as a drop-in (I might do that myself to make things quicker for me anyway).

Besides the API change, will adjusting EntityFrameworkMaterializer to actually do work asynchronously be complicated, do you think?

[SphtKr]

Re: the shim: I said that wrong, what I meant is a shim that would wait on the async versions and return the result synchronously. That would provide the old signatures.

[csantero]

Updating the EF materializer should be easy, there are Async versions of all the necessary methods.

I'm not sure about the utility of maintaining the old signatures in the interface. The only user is ApiController<>, and it would switch to using the async ones. Up to you, though.

[SphtKr]

I'm thinking selfishly about some of my code that uses EntityFrameworkMaterializer methods in my ApiController...writing a shim will let me worry about that later instead of touching multiple ApiControllers :-)

[csantero]

lol, alright. Let's try to remove them before 1.0 though.

[SphtKr]

Ohhh...yeah that's a problem with my shim idea I hadn't thought of, the only thing that would change in the method signature would be the return type, which you can't overload or subclass differently...therefore you changed all the async method names, right.

I'm of two minds about this: usually Async methods end with "Async", so that's sort of a convention...on the other hand, ending the method name with Async sort of implies that there's a non-Async version, which we don't want long-term.

Unsure which way to go here, but I'm okay with dropping my shim/legacy method signatures idea given that it had consequences on the long-term method naming. What do you think?

[SphtKr]

Should have researched this a little before replying...according to folks who seem to know, it seems that it's desirable to suffix methods that return a task with "Async" anyway. So I think the naming in your PR should probably stand, and we'll leave in the legacy versions for now.