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.
Arithmomaniac
commented
5 years ago
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.Baseproject/package that would contain BaseDto, relevant helper methods, and anIGravity(Async)Repositoryinterface containing a basic CRUD contract for all implementations. This would correspond to, e.g.RsapiDaonow.Gravity.RSAPI).IGravity(Async)Repositoryimplementation, which in turn would in turn take a thin provider to abstract away calls to and from the server (e.g.RsapiDaowould be renamedRsapiRepositorywould have anRsapiProvidersimilar 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 separateIQueryableGravityRepositoryimplementation, 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.