As mentioned in #70 , it may be time to start thinking about how we want to support multiple providers in the long run. I was thinking something as follows:
There would be a base Gravity.Base project/package that would contain BaseDto, relevant helper methods, and an IGravity(Async)Repository interface containing a basic CRUD contract for all implementations. This would correspond to, e.g. RsapiDao now.
Each implementation would get its own Nuget project/package, to prevent needing tons of dependencies (e.g. Gravity.RSAPI).
Each package would have the IGravity(Async)Repository implementation, which in turn would in turn take a thin provider to abstract away calls to and from the server (e.g. RsapiDao would be renamed RsapiRepository would have an RsapiProvider similar to the one in #70).
The repository itself would handle issues like field mapping, recursive calls, etc.
To implement IGravityRepository.Query, each provider would need to include a LINQ Provider, as per #12. We could have missing implementations throw NotSupportedException, create a separate IQueryableGravityRepository implementation, or just leave Query out of the base interface.
If this sounds right, we can decide how we'd like to create a project around it.
As mentioned in #70 , it may be time to start thinking about how we want to support multiple providers in the long run. I was thinking something as follows:
Gravity.Base
project/package that would contain BaseDto, relevant helper methods, and anIGravity(Async)Repository
interface containing a basic CRUD contract for all implementations. This would correspond to, e.g.RsapiDao
now.Gravity.RSAPI
).IGravity(Async)Repository
implementation, which in turn would in turn take a thin provider to abstract away calls to and from the server (e.g.RsapiDao
would be renamedRsapiRepository
would have anRsapiProvider
similar to the one in #70).IGravityRepository.Query
, each provider would need to include a LINQ Provider, as per #12. We could have missing implementations throwNotSupportedException
, create a separateIQueryableGravityRepository
implementation, or just leave Query out of the base interface.If this sounds right, we can decide how we'd like to create a project around it.