The new C# driver is totally Async and in my understanding twists a little bit the old design patterns such as DAL in n-tier architecture.
In my Mongo DALs I use to do:<
In my case: When I got this error:
The source IQueryable doesn't implement IAsyncEnumerable. Only sources that implement IAsyncEnumerable can be used for Entity Framework asynchronous operations.
I have implemented the async where function for mongodb as follows.
public async Task<IEnumerable<TEntity>> Where(Expression<Func<TEntity, bool>> expression = null)
{
return await context.GetCollection<TEntity>(typeof(TEntity).Name, expression).Result.ToListAsync();
}
It's helpful to understand the basics of async
/ await
because it's a somewhat leaky abstraction and has a number of pitfalls.
Essentially, you have two options:
Remain synchronous. In this case, it's safe to use .Result
and .Wait()
on the async calls, respectively, e.g. something like
// Insert:
collection.InsertOneAsync(user).Wait();
// FindAll:
var first = collection.Find(p => true).ToListAsync().Result.FirstOrDefault();
Go async in your code base. Doing it async is quite 'infectious', unfortunately, so either you convert pretty much everything to async, or not. Careful, mixing sync and async incorrectly will lead to deadlocks. Using async has a number of advantages, because your code can continue to run while MongoDB is still working, e.g.
// FindAll:
var task = collection.Find(p => true).ToListAsync();
// ...do something else that takes time, be it CPU or I/O bound
// in parallel to the running request. If there's nothing else to
// do, you just freed up a thread that can be used to serve another
// customer...
// once you need the results from mongo:
var list = await task;