Хабр Курсы для всех
РЕКЛАМА
Большая витрина: от крупнейших школ до частных авторов. Сравнивайте по цене, длительности, формату и выбирайте самый подходящий курс!
Хабр доступен 24/7 благодаря поддержке друзей
Комментарии 19
Не работал с MongoDB и его драйвером в .NET, зато принимал активное участие в проекте, где использовался NHibernate 3.1. Так вот там для операций над БД есть следующие инструменты: LINQ (Query), QueryOver, Criteria, HQL, возможно еще какие-то. Первые два — строго типизированные и используют Expression Tree, остальные — информация о типе хранится в строках.
В сложных выборках запрос на HQL/Criteria выглядит более понятным, нежели с LINQ (в QueryOver еще более тяжелые лексические конструкции). Однако команда все равно использовала QueryOver/Linq, просто потому что в противном случае рефакторинг становится существенно затруднительным.
Если динамика изменения модели предметной области Вашего проекта слабая, то Вы свободны выбирать между решениями, которые могут нарушать строгость типов. В этом случае вообще предпочтительнее использовать языки с динамической типизацией. В противном случае есть кактус имеет смысл — это ослабление риска.
P.S. я знаю о TDD и Unit-тестах, правда, я еще знаю и о том, какие проблемы с ними возникают в крупных проектах, а потому надеяться на них как на спасительную соломинку смысла не имеет. Все должно быть в комплексе: и тесты, и строгая типизация, где нужно.
В сложных выборках запрос на HQL/Criteria выглядит более понятным, нежели с LINQ (в QueryOver еще более тяжелые лексические конструкции). Однако команда все равно использовала QueryOver/Linq, просто потому что в противном случае рефакторинг становится существенно затруднительным.
Если динамика изменения модели предметной области Вашего проекта слабая, то Вы свободны выбирать между решениями, которые могут нарушать строгость типов. В этом случае вообще предпочтительнее использовать языки с динамической типизацией. В противном случае есть кактус имеет смысл — это ослабление риска.
P.S. я знаю о TDD и Unit-тестах, правда, я еще знаю и о том, какие проблемы с ними возникают в крупных проектах, а потому надеяться на них как на спасительную соломинку смысла не имеет. Все должно быть в комплексе: и тесты, и строгая типизация, где нужно.
ObjectId articleId = new ObjectId("dgdfg343ddfg");
IMongoQuery query = Query<Article>.EQ(item => item.Id, articleId);
Как по мне, перегруженная конструкция. Почему нельзя было сделать так:
IMongoQuery query = Query<Article>.EQ(item => item.Id, "dgdfg343ddfg");
Зачем еще какой-то объект создавать, пусть он сам создается.
Ну и дальше, пусть будет везде одинаковый стандарт. Мы же с коллекциями работаем. Взяли бы да выкинули Eq, а вместо этого всем привычный Where.
По поводу первого. Просто строку не указал, потому что люблю видеть какой тип у id в модели: здесь может быть как string так и ObjectId. MongoDB позволяет это делать.
Насчет второго. Да, можно Where, наверно и лучше, просто частенько приходится использовать ElemMatch или lt. А это уже совсем непривычно. Пусть уж лучше будет в стиле MongoDB для всего
Насчет второго. Да, можно Where, наверно и лучше, просто частенько приходится использовать ElemMatch или lt. А это уже совсем непривычно. Пусть уж лучше будет в стиле MongoDB для всего
Ну это было бы странно в данном случае. Where(...) подразумевает выражение-предикат, возвращающий bool.
Уважаемые специалисты/разработчики. Может быть, хоть кто-нибудь знает, как обойтись без магической строки в случае «array1.$.array2»?
Использую в промышленном проекте.
Честно не приходилось такие структуры делать, может быть стоит просто скорректировать дизайн? Например сделать вместо IEnumerable IDictionary, который сериализуется в нормальный документ (key/value), тогда и с магическими строками будет попроще.
Честно не приходилось такие структуры делать, может быть стоит просто скорректировать дизайн? Например сделать вместо IEnumerable IDictionary, который сериализуется в нормальный документ (key/value), тогда и с магическими строками будет попроще.
Спасибо. Буду пробовать. Но отсутствие самой возможности для любой структуры все равно настораживает
Alvaro, успешное использование mongodb практически обязывает на следующие ограничения:
— транзакционность на стороне программы (иначе будут дикие тормоза и сложности с шардингом/слейвами)
— преимущественно операции выполняются с одним документом (обратите внимание, что update по умолчанию происходит на ПЕРВЫМ документом подходящим по условию where).
При отсутствии транзакционности операции типа arr[i]=x очень чреваты, например, если кто-то параллельно будет делать вставку.
Поэтому народ использует массивы только когда точно знает что не нужно будет таких сложных операций. Ну а если и использует, то проще сделать обновление коллекции программно и отправить обратно на сервер всей пачкой.
— транзакционность на стороне программы (иначе будут дикие тормоза и сложности с шардингом/слейвами)
— преимущественно операции выполняются с одним документом (обратите внимание, что update по умолчанию происходит на ПЕРВЫМ документом подходящим по условию where).
При отсутствии транзакционности операции типа arr[i]=x очень чреваты, например, если кто-то параллельно будет делать вставку.
Поэтому народ использует массивы только когда точно знает что не нужно будет таких сложных операций. Ну а если и использует, то проще сделать обновление коллекции программно и отправить обратно на сервер всей пачкой.
Не могли бы вы подробнее рассказать про программные приемы/ограничения при шардинге.
Alvaro, не очень понял что хотели спросить. Проще по почте что-то конкретное.
Делаете шардинг — постарайтесь ограничиться обращением по id, вот весь совет.
Ну и в догонку: никогда не делайте в mongodb операций типа drop collection. Чревато полу-мертвой базой. Все опять же из за отключенной транзакционности для увеличения скорости работы.
Делаете шардинг — постарайтесь ограничиться обращением по id, вот весь совет.
Ну и в догонку: никогда не делайте в mongodb операций типа drop collection. Чревато полу-мертвой базой. Все опять же из за отключенной транзакционности для увеличения скорости работы.
Когда я писал свою реализацию типизированного UpdateBuilder'а для более ранней версии дляйвера, я сипользова Moq-style выражения. Выглядело это так.
Если вам интересно могу скинуть исходники на гитхаб
IMongoUpdate update = Update.PushWrapped<Item2>(array1[Is.Any<int>()].array2, new Item2());
Если вам интересно могу скинуть исходники на гитхаб
Зарегистрируйтесь на Хабре, чтобы оставить комментарий
MongoDB и C#. Новые возможности и неочевидные проблемы