Pull to refresh

Comments 11

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

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

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

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

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

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

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

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). Драйвер нормально типизирован и вполне современный
services.AddTransient<INoteRepository, NoteRepository>();

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


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

Sign up to leave a comment.