Pull to refresh

Comments 19

Не работал с MongoDB и его драйвером в .NET, зато принимал активное участие в проекте, где использовался NHibernate 3.1. Так вот там для операций над БД есть следующие инструменты: LINQ (Query), QueryOver, Criteria, HQL, возможно еще какие-то. Первые два — строго типизированные и используют Expression Tree, остальные — информация о типе хранится в строках.

В сложных выборках запрос на 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 для всего
Насчет первого, кстати, уже вопрос личных предпочтений и принятых в проекте гайд-лайнов. Я предпочитаю использовать var везде, где только возможно.

Насчет Eq(...) соглашусь, что пусть будет в стиле MongoDB. Ведь это не полноценный LINQ-провайдер, и будет путаница, если использовать Where(...).
Ну var понятно. Я не об этом, а о том, что надо создавать объект, который позже используется.
Ну это было бы странно в данном случае. Where(...) подразумевает выражение-предикат, возвращающий bool.
Уважаемые специалисты/разработчики. Может быть, хоть кто-нибудь знает, как обойтись без магической строки в случае «array1.$.array2»?
Использую в промышленном проекте.
Честно не приходилось такие структуры делать, может быть стоит просто скорректировать дизайн? Например сделать вместо IEnumerable IDictionary, который сериализуется в нормальный документ (key/value), тогда и с магическими строками будет попроще.
Спасибо. Буду пробовать. Но отсутствие самой возможности для любой структуры все равно настораживает
Alvaro, успешное использование mongodb практически обязывает на следующие ограничения:
— транзакционность на стороне программы (иначе будут дикие тормоза и сложности с шардингом/слейвами)
— преимущественно операции выполняются с одним документом (обратите внимание, что update по умолчанию происходит на ПЕРВЫМ документом подходящим по условию where).

При отсутствии транзакционности операции типа arr[i]=x очень чреваты, например, если кто-то параллельно будет делать вставку.

Поэтому народ использует массивы только когда точно знает что не нужно будет таких сложных операций. Ну а если и использует, то проще сделать обновление коллекции программно и отправить обратно на сервер всей пачкой.
Не могли бы вы подробнее рассказать про программные приемы/ограничения при шардинге.
Alvaro, не очень понял что хотели спросить. Проще по почте что-то конкретное.
Делаете шардинг — постарайтесь ограничиться обращением по id, вот весь совет.
Ну и в догонку: никогда не делайте в mongodb операций типа drop collection. Чревато полу-мертвой базой. Все опять же из за отключенной транзакционности для увеличения скорости работы.
Когда я писал свою реализацию типизированного UpdateBuilder'а для более ранней версии дляйвера, я сипользова Moq-style выражения. Выглядело это так.
IMongoUpdate update = Update.PushWrapped<Item2>(array1[Is.Any<int>()].array2, new Item2());

Если вам интересно могу скинуть исходники на гитхаб
Возможно там не все методы. Делал только нужные себе. Добавить новые там не составит проблем. Чуть что можете обращаться за помощью.
Большое спасибо. Если что, сам допилю нужное)
Only those users with full accounts are able to leave comments. Log in, please.