[CSHARP-1503] Can we mark IMongoQueryProvider as public? Created: 11/Dec/15 Updated: 13/Sep/21 Resolved: 13/Sep/21 |
|
| Status: | Closed |
| Project: | C# Driver |
| Component/s: | Linq |
| Affects Version/s: | 2.2 |
| Fix Version/s: | None |
| Type: | Improvement | Priority: | Minor - P4 |
| Reporter: | Potiguar Faga | Assignee: | Unassigned |
| Resolution: | Done | Votes: | 1 |
| Labels: | None | ||
| Remaining Estimate: | Not Specified | ||
| Time Spent: | Not Specified | ||
| Original Estimate: | Not Specified | ||
| Issue Links: |
|
||||
| Description |
|
Would it be possible to have the IMongoQueryProvider interface (https://github.com/mongodb/mongo-csharp-driver/blob/v2.2.0/src/MongoDB.Driver/Linq/IMongoQueryProvider.cs) marked as public? We are building a Framework that has built-in Async LINQ support, and for our mongodb data adapter it would make for extremely cleaner code if we could access ExecuteAsync<T> directly, instead of having to rewrite all the CountAsync, SumAsync etc (that are already coded inside the core of our framework). This interface is well documented, and does not have any properties of types that are not exposed, so it seems to me that it can be easily changed to public. Of course that means keeping backwards compatibility on the API from now on, but I think it can be useful for users of the C# driver in general to have access to it. |
| Comments |
| Comment by Dmitry Lukyanov (Inactive) [ 31/Aug/21 ] |
|
Hi, potz Thank you for the provided suggestion, but we have decided not to accept it. Mocking a third-party library - such as the MongoDB .NET Driver - is considered an anti-pattern because it hides changes in the mocked behaviour. The generally accepted solution is to encapsulate the dependency behind your own interface, which you can then mock and integration test. There has been much written on this topic, but this blog post is a good start with references to additional resources on the topic: https://dev.to/satansdeer/dont-mock-what-you-dont-own-cd6 If there is a particular problem that you are trying to solve that can't be solved using the encapsulation technique, please elaborate further as there may be other solutions to consider. Sincerely, |
| Comment by Maxime Caroul [ 05/Apr/18 ] |
|
+1 as Greg said, my choices are all bad too for unit testing. I guess that a new version of the driver will be released with mongodb v4.0. |
| Comment by Greg Lincoln [ 01/Feb/18 ] |
|
Any chance this could be changed soon? It is just one word (with implications beyond that, I realize. Right now, my choices are all bad. I can either give up the niceties of IMongoQueryable (the async stuff, mostly), roll my own version of the driver, or skip testing any of my logic after an AsQueryable call. Note that the subject of this task should be changed, as it is about IMongoQueryProvider not IMongoQueryable. |
| Comment by Potiguar Faga [ 11/Dec/15 ] |
|
Understood. Thanks for the quick answer. I can certainly use a custom-built version of the driver for now. |
| Comment by Craig Wilson [ 11/Dec/15 ] |
|
Hi Potiguar, Thanks for the question. We'll certainly consider it. The reason it's not public currently is that we thought we might need to change this interface in the future if we were to transition over to Relinq (for instance). Give us some time to think it over and come up with an answer. It won't happen before 2.3.0 which is a little ways off (targeting .NET Core support for that release). Until then, I'd suggest you build a custom version of the driver to ensure that simply making this public actually solves your needs. There might be other work that would need to occur internally if, for instance, your CountAsync method and ours don't play well together. Craig |