ну да, он и в посте так написан (за исключением AsEnumerable()).
Я просто хотел подчеркнуть, что при использовании NH не возникает желания вставить GroupBy «не туда», потому что NH заставляет задумываться о том, что идет в SQL, а что — в пост-обработку, не возникает смешения за счет одинаковости синтаксиса (как в EF).
При этом я не говорю, что это минус ЕФа, для многих единство синтаксиса как раз весомый плюс (как для автора, например, судя по комменту выше)
Мне четкие различия: где SQL, а где Linq, наоборот, нравятся. Нравятся четким представлением, что за запрос отправится в базу и угадыванием момента, когда пора оптимизировать.
Люди, хорошо знакомые с Linq, начнут писать запросы на EF быстрее, чем если бы они изучали NH. Тем, кто хорошо знаком с SQL, но мало — c Linq, наоборот будет проще стартовать с NH.
А когда знаешь и то, и другое — это на вкус и цвет :)
Ну и в принципе — обе системы неплохи, с этим не поспоришь.
Вот в частности за это мне и нравится NHibernate. За то, что он даёт удобный способ написания старых-добрых SQL-запросов, а не предлагает некую «магию». Таким образом, когда пишешь сложный запрос к БД, задумываешься о том, как он будет выглядеть на SQL.
А в случае простых запросов — ну он такой же, как ЕФ :)
1) пришедшие из программистов(=технарей) менеджеры часто плохи как менеджеры.
2) менеджеры, которые хороши как менеджеры часто нетехнари.
пункты про разных людей
Оценки важны не только для абсолютной оценки фичей, а скорее для относительной.
Чтобы заказчик — product owner — понимал, что вот эта фича в два раза дольше другой, а вот эта, наоборот, в полтора раза проще.
И соотносил это понимание с важностью той или иной штуки и менял приоритеты.
С учетом понимания между командой и заказчиком это весомый аргумент за оценки.
А к вопросу траты времени — это и не должно занимать много. Если не пытаться оценить с точностью до миллиметра и не спорить при малейших расхождениях. Оценка, к тому же, стимулирует к разбиению крупных задач и более четкому представлению о грядущем и о распределении тасков внутри команды.
«То, что народ пользуется это говорит лишь о слаборазвитой конкуренции или её отсутствии»
Да ладно, как будто появись конкурент с благозвучным названием все уйдут, ага. Стабильно проходящие платежи, обилие терминалов, комиссия. Вот что важно.
А дизайн и название… удобный диз — лишний повод «обсудить» с друзьями = реклама. То есть это хорошо, да. Но не ключевой фактор.
Просто неоднократно с этим сталкивался — может, тоже на снапшотах предыдущего релиза, но отложилось в памяти, как будто и в релизе такое поведение тоже было (заранее извиняюсь, если неправ :)).
Ну а то, что это прошло тестирование незамеченым — это как-то совсем нереально, потому сомнения и закрались :)
Если баг только в снапшотах — my bad :)
Все хорошо, только мне не очень понятно, зачем при каждом обновлении опера упорно добавляет мне в закладки — а теперь еще и на спид-дайл — спонсорские странички озона\мэйлру\яндекса и т.д.?
При первой установке — это мне вполне понятно. Но при обновлениях-то зачем? Хоть бы в закладках добавлялись в какую-нибудь папку для быстрого удаления всего и разом (а может я бы и оставил эту папку, глаза не мозолит и ладно) — так нет же, в корень…
Вы — хороший ПМ. От вас прятать баги не надо.
А бывает, к сожалению, наоборот. Когда путем такого вот сокрытия разработчики приоритезируют баги и фиксят то, что более актуально, а не то, что «внезапно выскочило». А всё новое и внезапное у начальства почему-то в приоритете «по-умолчанию». И надо срочно переключаться, терять контекст итд/итп.
В идеальном мире надо менять такое отношение начальства, да. Но столкнувшись с ситуацией надо её решать сейчас, а не в перспективе.
//у нас не всё так плохо, но иногда бывает :) и я с сожалением представляю, что у кого-то еще это может быть не «иногда», а постоянно.
требует линковки готового продукта со своими библиотеками, что делает нас зависимыми от него.
Проприетарность, и возможная платность в будущем.
Некоторые негативные отзывы о производительности — но это на личном примере не проверялось.
Это вкупе, ну и относительная простота собственной реализации и подтолкнули к Mono.Cecil.
ну да, я поэтому и плюсанул исходный комментарий, что полностью с ним согласен. Это классическая задача АОП.
И именно поэтому я и не расписываю пути «как я решал эту сложнейшую проблему» :) Просто представил результат, потому что в готовом виде ничего подобного (кроме log4postsharp уже упоминавшегося) не нашел.
логирование параметров происходит только при указании атрибута [Log(true)]. В случаях, когда вызов ToString является проблемой, параметры можно не логировать.
Лично я «по умолчанию» логирую-таки без параметров, а с ними — на ключевых стадиях процесса, в ключевых менеджер-классах.
ну я тоже удивился, что нигде нет именно готовой реализации. Если я-таки свилосипедил, то киньте ссылкой на проект, буду благодарен.
А говорят об этом везде, да. На уникальность идеи\реализации не претендую :)
Большого смысла нет.
Платят мало пока студент и ничего не умеет толком. Научится-вырастет-станет полезным — попросит соответствующую зарплату.
Единственный плюс — «лояльность фирме», которая вырастила тебя как специалиста. Но это от человека к человеку очень разное, ну и от повышения зарплаты никоим образом не спасает :)
Искать выдающихся студентов и брать к себе — это да, но здесь причина не в «платить мало», а в «застолбить специалиста» скорее :)
У NH 3.1 такой синтаксис «из коробки».
Я просто хотел подчеркнуть, что при использовании NH не возникает желания вставить GroupBy «не туда», потому что NH заставляет задумываться о том, что идет в SQL, а что — в пост-обработку, не возникает смешения за счет одинаковости синтаксиса (как в EF).
При этом я не говорю, что это минус ЕФа, для многих единство синтаксиса как раз весомый плюс (как для автора, например, судя по комменту выше)
Люди, хорошо знакомые с Linq, начнут писать запросы на EF быстрее, чем если бы они изучали NH. Тем, кто хорошо знаком с SQL, но мало — c Linq, наоборот будет проще стартовать с NH.
А когда знаешь и то, и другое — это на вкус и цвет :)
Ну и в принципе — обе системы неплохи, с этим не поспоришь.
А в случае простых запросов — ну он такой же, как ЕФ :)
На NH пример выше выглядел бы как:
ну и SQL был бы в результате чуть-чуть оптимальнее:
а засунуть GroupBy-часть в SQL не было бы даже мысли, потому что sql-group-by здесь просто не нужен (он оставил бы из всех Заказов только один).
2) менеджеры, которые хороши как менеджеры часто нетехнари.
пункты про разных людей
Чтобы заказчик — product owner — понимал, что вот эта фича в два раза дольше другой, а вот эта, наоборот, в полтора раза проще.
И соотносил это понимание с важностью той или иной штуки и менял приоритеты.
С учетом понимания между командой и заказчиком это весомый аргумент за оценки.
А к вопросу траты времени — это и не должно занимать много. Если не пытаться оценить с точностью до миллиметра и не спорить при малейших расхождениях. Оценка, к тому же, стимулирует к разбиению крупных задач и более четкому представлению о грядущем и о распределении тасков внутри команды.
А куда можно отправить ваши «примеры задач» проверки ради?
Да ладно, как будто появись конкурент с благозвучным названием все уйдут, ага. Стабильно проходящие платежи, обилие терминалов, комиссия. Вот что важно.
А дизайн и название… удобный диз — лишний повод «обсудить» с друзьями = реклама. То есть это хорошо, да. Но не ключевой фактор.
Ну а то, что это прошло тестирование незамеченым — это как-то совсем нереально, потому сомнения и закрались :)
Если баг только в снапшотах — my bad :)
В таких случаях часто не поймешь — баг это или фича :)
При первой установке — это мне вполне понятно. Но при обновлениях-то зачем? Хоть бы в закладках добавлялись в какую-нибудь папку для быстрого удаления всего и разом (а может я бы и оставил эту папку, глаза не мозолит и ладно) — так нет же, в корень…
ну решение тоже более-менее стандартно вроде бы.
блокировка перед изменением «общего» ресурса вроде обычный подход, нет?
А бывает, к сожалению, наоборот. Когда путем такого вот сокрытия разработчики приоритезируют баги и фиксят то, что более актуально, а не то, что «внезапно выскочило». А всё новое и внезапное у начальства почему-то в приоритете «по-умолчанию». И надо срочно переключаться, терять контекст итд/итп.
В идеальном мире надо менять такое отношение начальства, да. Но столкнувшись с ситуацией надо её решать сейчас, а не в перспективе.
//у нас не всё так плохо, но иногда бывает :) и я с сожалением представляю, что у кого-то еще это может быть не «иногда», а постоянно.
Но и коммьюнити в один прекрасный момент может стать платной
Проприетарность, и возможная платность в будущем.
Некоторые негативные отзывы о производительности — но это на личном примере не проверялось.
Это вкупе, ну и относительная простота собственной реализации и подтолкнули к Mono.Cecil.
И именно поэтому я и не расписываю пути «как я решал эту сложнейшую проблему» :) Просто представил результат, потому что в готовом виде ничего подобного (кроме log4postsharp уже упоминавшегося) не нашел.
Лично я «по умолчанию» логирую-таки без параметров, а с ними — на ключевых стадиях процесса, в ключевых менеджер-классах.
А говорят об этом везде, да. На уникальность идеи\реализации не претендую :)
Платят мало пока студент и ничего не умеет толком. Научится-вырастет-станет полезным — попросит соответствующую зарплату.
Единственный плюс — «лояльность фирме», которая вырастила тебя как специалиста. Но это от человека к человеку очень разное, ну и от повышения зарплаты никоим образом не спасает :)
Искать выдающихся студентов и брать к себе — это да, но здесь причина не в «платить мало», а в «застолбить специалиста» скорее :)