Будут. Но на практике, основной проблемой, с которой мы сталкивались, оказалось — приучить коллег проверять, у каждого ли проекта в солюшене выставлена правильная конфигурация в Configuration Manager. И не забывать добавлять наши кастомные конфигурации для новых проектов, что, впрочем, легко диагностировалось по падению сборки на билд-сервере.
А можно просто создать по конфигурации на бранч и включить трансформацию конфигов при каждой сборке проекта (не путать с трансформацией при деплое). Например, так:
То, что собранный Web.Config будет попадать в pending changes — не имеет никакого значения, поскольку он все равно перезапишется при следующем билде соответственно выбранной конфигурации. Оригинал хранится в Web.Base.Config и правится редко. На билд-сервере трансформация тоже будет работать.
Hangfire – отличное решение, но, вроде, сразу требует использования базы данных для хранения очереди задач. Да и не совсем там все бесплатно – есть и платная версия.
Вроде? Вы их не запускали, что ли, когда сравнивали?
Чтобы внести ясность: да, Hangfire-у для работы необходима БД на SQL Server. В этой базе хранится очередь, через нее же синхронизируются процессы, выполняющие задачи из очереди. Приятный бонус такого подхода — "из коробки" работает кластеризация, т.е. распараллеливание процесссов-обработчиков. В платной версии хранилищем задач может выступать Redis, и есть ряд синтаксических вкусностей (прекрасно обходились и без них). Код бесплатной версии открыт, и репозиторий уже становится популярнее Квартца, хотя Hangfire на много лет моложе.
И непонятно почему из него можно сделать SelectMany, а не Select.
Непонятно будет только тем, кто не понимает SelectMany, как вы считаете? С моей точки зрения, оба варианта читаются одинаково, но вариант с extention method проще технологически. Впрочем, было бы интереснее узнать, генерит ли EF эквивалентный SQL в обоих случаях.
Ничего страшного в деревьях выражений нет — очень мощный и гибкий механизм.
К сожалению, со своими ограничениями (часть из списка уже пофиксили) и относительно медленным компилятором (люди пишут свои).
Представьте, что у вас большой проект и в репозитории 100 методов вида: All, AllActive, AllActivePerCustomer, AllActivePerCustomerByDate… это не мусорка? Один из вариантов убрать дублирование кода из полученного репозитория — построить запросы через методы-расширения вида IQueryable Active(this IQueryable queriable), о которых, внезапно — упоминал Bonart. Следующий шаг — выкинуть методы репозитория за ненадобностью и строить запросы в сервисном слое из типовых методов-расширений.
Вы, конечно же, можете возразить — вместо 100 методов в репозитории будет один метод GetFiltered(query). Что есть query? Если IQueryable — то см. выше. А если писать запросы на самодельном DSL, то есть вероятность, что для большого проекта в итоге получится дорогая и ограниченная… надстройка над LINQ.
Успешная регистрация, даже в МЧС напрямую — вовсе не означает, что вас будут активно искать в разумные сроки, и вообще будут ли. Самым надежным был и остается человек в городе, который начнет всех тормошить в случае невыхода группы на связь.
Вы хотите сказать, что длительная однократная задача (например, добавленная через BackgroundJob.Enqueue) может быть выполнена многократно? Как это воспроизвести? В моем случае, долговременные (2-4 часа) задачи выполняются строго 1 раз, иначе Hangfire было бы сложно воспринимать всерьез =)
Будут. Но на практике, основной проблемой, с которой мы сталкивались, оказалось — приучить коллег проверять, у каждого ли проекта в солюшене выставлена правильная конфигурация в Configuration Manager. И не забывать добавлять наши кастомные конфигурации для новых проектов, что, впрочем, легко диагностировалось по падению сборки на билд-сервере.
А можно просто создать по конфигурации на бранч и включить трансформацию конфигов при каждой сборке проекта (не путать с трансформацией при деплое). Например, так:
Web.Base.Config + Web.$(Configuration).config = Web.ConfigТо, что собранный
Web.Configбудет попадать в pending changes — не имеет никакого значения, поскольку он все равно перезапишется при следующем билде соответственно выбранной конфигурации. Оригинал хранится вWeb.Base.Configи правится редко. На билд-сервере трансформация тоже будет работать.Этот пакет я и имел ввиду. Возможно, raptor знает что-то еще?
Да и в соседней ветке комментариев подсказывают про Hangfire.Redis.StackExchange.
Судя по http://hangfire.io/pro/#hangfireproredis и состоянию пакета Hangfire.Redis — всё таки платно. Был бы рад ошибиться.
Ваша правда. Забыл, что к Hangfire все-таки можно прикрутить in-memory storage.
Вроде? Вы их не запускали, что ли, когда сравнивали?
Чтобы внести ясность: да, Hangfire-у для работы необходима БД на SQL Server. В этой базе хранится очередь, через нее же синхронизируются процессы, выполняющие задачи из очереди. Приятный бонус такого подхода — "из коробки" работает кластеризация, т.е. распараллеливание процесссов-обработчиков. В платной версии хранилищем задач может выступать Redis, и есть ряд синтаксических вкусностей (прекрасно обходились и без них). Код бесплатной версии открыт, и репозиторий уже становится популярнее Квартца, хотя Hangfire на много лет моложе.
Масштабируемость, отказоустойчивость, персистентность?
И Go# пожалуйста =)
поправил верстку, теперь всё =) спасибо
del
UPD: насколько я помню, SqlBulkCopy все-таки генерирует SQL, а именно BULK INSERT команду.
читаем внимательно
если вам так принципиально, можете читать мой предыдущий комментарий как трудозатраты на реализацию аналога IQueryProvider
А зачем? Можно пример? Неужели отбиваются трудозатраты на реализацию IQueryProvider?
Непонятно будет только тем, кто не понимает SelectMany, как вы считаете? С моей точки зрения, оба варианта читаются одинаково, но вариант с extention method проще технологически. Впрочем, было бы интереснее узнать, генерит ли EF эквивалентный SQL в обоих случаях.
К сожалению, со своими ограничениями (часть из списка уже пофиксили) и относительно медленным компилятором (люди пишут свои).
Вы, конечно же, можете возразить — вместо 100 методов в репозитории будет один метод GetFiltered(query). Что есть query? Если IQueryable — то см. выше. А если писать запросы на самодельном DSL, то есть вероятность, что для большого проекта в итоге получится дорогая и ограниченная… надстройка над LINQ.
По западной классификации — есть. https://en.wikipedia.org/wiki/AK-47