SimbirSoft corporate blog
Programming
.NET
MongoDB
API
Comments 11
+1
Как обстоит дело с производительностью? Слышал, что Mongo давно уступила первенство Postgres NoSQL…
Тут, например, смотрел.
Или уже что-то изменилось с тех пор?
0
Из сравнений наиболее актуальных версий (PostgreSQL 9.5b1 и MongoDB 3.2.0) можно упомянуть доклад на PgConf.Russia 2016 где рассматриваются результаты выполнения основных операций и рассказывается, почему и при каких условиях так получилось.:)
С нетерпением ждём сравнение производительности MongoDB 3.4 и PosgreSQL 9.6!
+1

Небольшое замечание: в реализации методов репозитория можно напрямую возвращать Task или Task без async/await. Если же async/await необходим, рекомендуется await SomeJob().ConfigureAwait(false); — просто хорошая практика, почитайте в гугл.

0
Спасибо за комментарий, обязательно учтём в следующих публикациях!
P.S. информацию по этой теме также можно почитать на хабре.
0
Это вам гугл сказал, что это хорошая практика? Вы весь свой код уже утыкали ConfigureAwait(false)?
Разобрались бы сначала где и для чего это используется, чем вот так вот советовать, ссылаясь на Google
+1
.ConfigureAwait(false); нужен чтобы избежать дедлока при вызове .Wait() из потока имеющего контекст (WPF или ASP.Net).

Утыкивая свой код .ConfigureAwait(false); вы делаете его длинным и некрасивым ради того, чтобы кто-то мог использовать порочные практики вызывая .Wait в асинхронном коде. К сожалению это повсевместно рекомендуемое решение…

Подробнее по ссылке: https://blog.stephencleary.com/2012/07/dont-block-on-async-code.html
0
Если вы разрабатываете библиотеки и не контролируете вызываемый код, тогда это нужно делать.
Обычный код засорять такими вещами совершенно не нужно и если у вас есть товарищи, которые используют порочные практики — заворачивайте их на ревью.
0

Вообще-то в статье речь про ASP.NET Core. Где SynchronizationContext отсутствует в принципе. Поэтому ConfigureAwait(false) имеет смысл только из соображений обратной совместимости с classic ASP.NET и проч.
P.S. Подкрепить свои слова ссылкой — и куда более весомо, и куда вежливей, чем посылание в гугл.

+2
Спасибо за статью, новичкам будет полезно, но есть несколько замечаний:

1) services.Configure(options =>
Зачем выковыривать каждую настройку, если сделали удобный маппинг всего объекта на JSON?

2) Для connectionString достаточно одной строки и
new MongoUrl(«mongodb://localhost:27017/test») спокойно вам отдаст и connectionString и DatabaseName

3) services.AddTransient<INoteRepository, NoteRepository>()
MongoClient — это SMART клиент, который нужен всего один на приложение. (исключения составляют особые случаи). MongoClient сам заботится о переподключении, о connection pool и.т.п, поэтому регайте NoteContext как Singleton.

4) Builders.Filter.Eq(«Id», id) превращается в обычную лямбду (x => x.Id == id). Драйвер нормально типизирован и вполне современный
+1
services.AddTransient<INoteRepository, NoteRepository>();

Я бы все-таки сделал Scoped, если храните какой-то кеш на запрос, либо, как отметил ZOXEXIVO, Singleton. Раньше по-крайней мере клиент к монге именно так работал и не было смысла создавать несколько инстанцев коннекта, в последних версиях может что-то и поменялось, не смотрел...


По поводу async-методов, не стоит реализовывать в репозитории только такие методы, они парами должны быть доступны (UpdateNote и UpdateNoteAsync), дело в том, что механизм выполнения асинхронных методов сложен и требует больших затрат в приложении, а, к примеру, достать запись по Id, выполнится быстрее, чем само создание объекта Task (условно). И помните, что таким образом Вы раздуваете конечный автомат (см. ссылку)

Only those users with full accounts are able to leave comments.  , please.