Автор чем занимается? Маркеты? Тонна dto это про заказы, товары и быстро сложить в БД. Предлагаю автору решить прикладную задачу от МЧС - матмодель поведения облака хлора в плотной городской застройке под действием различных погодных условиях. Программа позволяла быстро "построить" город (указывались дома, этажность, подъездность), размещались на карте, указать откуда и с какой силой дует ветер и в какой точке собственно авария. Пилот проект строился на расчете облака хлора. В решении задачи надо было рассчитать движение масс воздуха, междомовых "сквозняков" и с учетом физических свойств визуализировать движение хлора. Движение воздуха, влага, хлор - все билось на метачастицы, им прописывалась физика поведения, это все обсчитывалось и визуализировалось. И вся эта задачка призвана спасать жизни людям. И в ней огромное количество именно ООП и практически полное отсутствие dto.
Я сейчас зашел посмотрел цены, они стали намного более реалистичными. Появились комьюнити версии. А почти 15 лет назад редакция Архитектор была 40к. И именно она включала в себя лицензии на все предыдущие продукты, в число которых входила и необходимая 7-ка. Нолик не лишний.
Был крупный десктоп проект, который пережил несколько реинкарнаций. Брал он начало в Delphi 2.0 и закончил боевой путь в Delphi 7. В один момент, случилось так, что надо было систему "легализовать", много экземпляров установлено было в компаниях требовавших лицензионной чистоты. И пошли мы искать лицензию на семерку. И нашли в недрах компании Embarcadero. Нам много не надо было, просто лицензию на Delphi 7, на три рабочих места. По всем нашим необходимостям этого хватало. Связались с отделом продаж, и оказалось, что на тот момент лицензия на семерку входит в пакет РадСтудио. И что для нашей компании ценник 40 000+$ за одно рабочее место. Как сейчас не знаю, но на 2011 год ценник был такой. Прайс лег на стол начальству, а с понедельника был утвержден пилот проект перехода (на тот момент) на net 3.5 По состоянию на сегодняшний день проект уже давно живет на net-8, приобрел не только десктоп версии, но и вэб, широкую серверную инфраструктуру и много еще чем прирос.
Embarcadero не пожадничай, остались бы на Delphi и проект бы умер. Было слияние компаний, и у поглощающей компании на серверах все крутилось на .net , и благодаря тому что наша система уже была переписана все интегрировалось почти без потрясений.
Самое интересное что анти-прививочники не против прививок и вакцин как таковых.
Они против методов прививания, качества и состава вакцин.
Методы- завезли вакцину, всех поголовно привили, часть привитых смогли откачать, часть похоронили, часть перевели на инвалидность. Антипрививочники выступают за то, что любая прививка должна быть предварена тщательными исследованиями и анализами на на отсутствие побочных последствий для каждого прививаемого. Да это не дешево и так позволят себе прививаться только состоятельные люди.
Качество — закупили уеву тучу прививок от гриппа приперли ее в страну, по выходу оказалось что транспортировка была не надлежащей, вакцина ехала в обычном контейнере без соблюдения температурных норм в результате чего приехали бесполезные ампулы. Более того вторым пунктом оказалось что привезли вакцину от штамма который на данной территории встречается 1 на 100000 случаев. То есть изначально бесполезная. Результат коррупции и прямых госзакупок.
Состав — использование тяжелых металлов и ядов и неочевидных составов, которые не разглашаются производителями под покровом коммерческой тайны.
Вот три основных претензии антипрививочников.
А теперь о последствиях. Когда вы говорите о том что побочные эффекты мизерны и составляют всего 0,1% это вселяет радость. Но вот как только Ваш единственный ребенок который бегал, прыгал, был жизнерадостным на второй день после прививки сел лицом к стенке и просто на одной ноте 8 (ВОСЕМЬ !!) суток кричал, потом потерял речь, получил деградацию головного мозга, полная дегенерация развития и за последующие 5 лет стал «овощем», побочные эффекты для ВАС станут 100%, не смотря на общую статистику. И это реальный случай из жизни.
И каждый решает готов он рисковать делая прививки или нет.
Или выступать за отмену прививок пока они не будут иметь гарантировано отсутствие побочек.
Ну и статистика смертности и побочных эффектов вещь никогда не сравниваемая ни производителями ни медиками. Если умерло 140000 человек в мире, это 1,3%, значит заболело почти 11млн человек. Если побочные эффекты у 0,1% вакцинированных то достаточно просто вакцинировать 110млн человек чтоб получить 140 000 смертей инвалидностей и тд. А если вакцинировать больше? А стоит ли вакцинация этого?
Ну и напоследок. До массовой вакцинации наблюдался спад эпидемий и болезней в тех регионах где происходило улучшение уровня жизни. Проще говоря там где антисанитария там и болели, что мы наблюдаем и ныне. После введения массовой вакцинации вообще ничего не поменялось.
Подробнее про это можете поискать фильм по вакцинации в СССР. (Был на Ютубе, сейчас названия не вспомню)
Ну и по поводу автоматического сканирования. Мой текущий проект содержит порядка полторы сотни различных сервисов, простыня из AddSingleton/AddTransient значительно перегружает конфигурацию. Я использую пометку атрибутом [SingletonService]/[TransientService], и сканированием регистрирую именно их. Очень удобно, и не надо волноваться забыл ты зарегестрировать или нет. Более того, если сборку под проект делает другой человек, а мы их подключаем через нугет-репозиторий, то ему достаточно пометить атрибутом и его сервисы также будут зарегистрированы. Таким образом, если я использую какую либо зависимость, а она имеет еще 20-30 своих зависимостей, то простыню моих 150 сервисов расширять еще 30 не нужно. Единственный момент, о сканировании надо помнить, потому как это не явная регистрация зависимостей.
Scrutor позволяет указать какие сборки сканировать. Но с другой стороны все это у нас не что иное как Back, и как показывает мой опыт, первые же клиенты подключившиеся к сервису заставят прогрузится все сборки, так что я не вижу особой разницы в моменте их загрузки, при первом вызове или при сканировании. Более того второй вариант мне кажется предпочтительней. Хотя конечно мой опыт не перекрывает все возможные сценарии.
Важно! Автоматическая регистрация работает только для работ, определенных в той же сборке, что и код, вызвавший метод регистрации. Работы из других сборок придется регистрировать вручную.
Возможно https://github.com/khellang/Scrutor помог бы зарегестрировать работы определенные и в других подключенных сборках. Если конечно сами сборки не грузить ручками.
Почему они должны быть тонкими? — ни слова.
Какой в этом плюс? — ни слова.
Как сделать их тонкими, если они сейчас не такие? — ни слова.
Как сохранить их тонкими? — ни слова.
О чем заметка? Просто сообщить о нескольких проблемах?
Лично я зашел почитать ответы на те 4 вопроса которые Вы задали в начале. Но их почему-то нет.
Если Вы возмущены, Ваши конкуренты в своих презентация напрямую говорят что Ваш продукт «отстой», Вы вполне не имеете этических ограничений чтоб такую статью представить с прямым указанием на конкурента и сделать в две колонки — «Как у них, и вот так у нас».
С одной стороны статья перестанет складывать впечатление «обиженной девочки», с другой вы такую статью действительно сможете давать клиентам как сравнение продуктов.
Лично меня не покидает ощущение изложения в статье легкой формы истерики. И как клиент я сразу задумаюсь, а стоит ли связываться с компанией менеджмент которой впадает в истерику при столкновении с «черным» пиаром.
ORM позволяет абстрагироваться от БД. Паттерн «Хранилище» добавляет абстрагирование от ORM.
Мне вот интересен реальный пример, когда проект необходимо переводить на другую ORM.
Может скажете что на этапе проектирования не была учтена производительность ORM? Но тогда Вы просто не читали ТЗ.
Переход на другую ORM не праздный вопрос. Мне действительно интересна ситуация когда возникает необходимость перехода.
За все долгое время моего программирования пару раз сталкивался с ситуацией когда ORM просаживала производительность. Но каждый раз это были настолько нагруженные места, что и реляционная БД не справлялась с пиками, так что вопрос решался или построением очереди на запись в памяти или сбросом на диск с последующим переносом в БД. Объясните мне необходимость абстракции от ORM кроме желания прикрутить еще один паттерн.
Поэтому и спросил как Вы решаете подобный вопрос используя WebApi. В частности я для данной задачи использую NATS, он подошел лучше всего по производительности.
На проекте которым я сейчас занимаюсь более 200 рабочих сервисов. Они одинаковые, но каждый занимается обработкой своей группы данных. Так как это все крутится на выделенных серверах, иногда возникает ситуация когда некоторые сервисы сгруппированные на одном сервере необходимо перемещать на менее загруженные сервера или резервный сервер. Ситуация редкая но встречается.
Есть ситуация когда управляющий сервис, а с ним общается вся пачка из 200-т воркеров на постоянной основе, надо обновлять не останавливая работу. Мы поднимаем обновленный сервис и переводим на него работу всех воркеров.
Таже самая ситуация в обратную сторону, при переносе сервиса-воркера на другой сервер или виртуалку сервисы работающие с фермой должны отслеживать их перемещение. Если это один сервис, то еще ничего, а если их десяток?
У вас есть N ДЦ, в которых подняты идентичные системы, но обслуживают разные регионы. Например Европа-США-Азия, очень распространенный вариант размещения для увеличения отзывчивости. Предположим падает сервис или хостер уронил виртуалку или произошел непредвиденный сбой. Самый простой способ чтоб на время сбоя сервисы поднятые в других ДЦ перехватили работу павшего собрата, до момента его подъема.
А как Вы решаете проблему передачи данных на несколько сервисов, со сложным роутингом, размещением сервисов в региональных ДЦ? В случае постройки работы проекта на WebApi разворот потоков данных фермы достаточно не простая задача.
Автор чем занимается? Маркеты? Тонна dto это про заказы, товары и быстро сложить в БД.
Предлагаю автору решить прикладную задачу от МЧС - матмодель поведения облака хлора в плотной городской застройке под действием различных погодных условиях.
Программа позволяла быстро "построить" город (указывались дома, этажность, подъездность), размещались на карте, указать откуда и с какой силой дует ветер и в какой точке собственно авария. Пилот проект строился на расчете облака хлора. В решении задачи надо было рассчитать движение масс воздуха, междомовых "сквозняков" и с учетом физических свойств визуализировать движение хлора. Движение воздуха, влага, хлор - все билось на метачастицы, им прописывалась физика поведения, это все обсчитывалось и визуализировалось.
И вся эта задачка призвана спасать жизни людям.
И в ней огромное количество именно ООП и практически полное отсутствие dto.
Я сейчас зашел посмотрел цены, они стали намного более реалистичными. Появились комьюнити версии. А почти 15 лет назад редакция Архитектор была 40к. И именно она включала в себя лицензии на все предыдущие продукты, в число которых входила и необходимая 7-ка. Нолик не лишний.
Был крупный десктоп проект, который пережил несколько реинкарнаций. Брал он начало в Delphi 2.0 и закончил боевой путь в Delphi 7.
В один момент, случилось так, что надо было систему "легализовать", много экземпляров установлено было в компаниях требовавших лицензионной чистоты.
И пошли мы искать лицензию на семерку. И нашли в недрах компании Embarcadero. Нам много не надо было, просто лицензию на Delphi 7, на три рабочих места. По всем нашим необходимостям этого хватало.
Связались с отделом продаж, и оказалось, что на тот момент лицензия на семерку входит в пакет РадСтудио. И что для нашей компании ценник 40 000+$ за одно рабочее место. Как сейчас не знаю, но на 2011 год ценник был такой.
Прайс лег на стол начальству, а с понедельника был утвержден пилот проект перехода (на тот момент) на net 3.5
По состоянию на сегодняшний день проект уже давно живет на net-8, приобрел не только десктоп версии, но и вэб, широкую серверную инфраструктуру и много еще чем прирос.
Embarcadero не пожадничай, остались бы на Delphi и проект бы умер. Было слияние компаний, и у поглощающей компании на серверах все крутилось на .net , и благодаря тому что наша система уже была переписана все интегрировалось почти без потрясений.
И как только надо было сделать в контроле шаг влево-вправо, начиналось, как в преферансе - "кровавые 10".
(Hamster kombat, PixelTap, Catizen,Rocky Rabbit‑ тут нет по понятным причинам)
А для тех кого "тапалки" обошли стороной, можно объяснить причины?
Они против методов прививания, качества и состава вакцин.
Методы- завезли вакцину, всех поголовно привили, часть привитых смогли откачать, часть похоронили, часть перевели на инвалидность. Антипрививочники выступают за то, что любая прививка должна быть предварена тщательными исследованиями и анализами на на отсутствие побочных последствий для каждого прививаемого. Да это не дешево и так позволят себе прививаться только состоятельные люди.
Качество — закупили уеву тучу прививок от гриппа приперли ее в страну, по выходу оказалось что транспортировка была не надлежащей, вакцина ехала в обычном контейнере без соблюдения температурных норм в результате чего приехали бесполезные ампулы. Более того вторым пунктом оказалось что привезли вакцину от штамма который на данной территории встречается 1 на 100000 случаев. То есть изначально бесполезная. Результат коррупции и прямых госзакупок.
Состав — использование тяжелых металлов и ядов и неочевидных составов, которые не разглашаются производителями под покровом коммерческой тайны.
Вот три основных претензии антипрививочников.
А теперь о последствиях. Когда вы говорите о том что побочные эффекты мизерны и составляют всего 0,1% это вселяет радость. Но вот как только Ваш единственный ребенок который бегал, прыгал, был жизнерадостным на второй день после прививки сел лицом к стенке и просто на одной ноте 8 (ВОСЕМЬ !!) суток кричал, потом потерял речь, получил деградацию головного мозга, полная дегенерация развития и за последующие 5 лет стал «овощем», побочные эффекты для ВАС станут 100%, не смотря на общую статистику. И это реальный случай из жизни.
И каждый решает готов он рисковать делая прививки или нет.
Или выступать за отмену прививок пока они не будут иметь гарантировано отсутствие побочек.
Ну и статистика смертности и побочных эффектов вещь никогда не сравниваемая ни производителями ни медиками. Если умерло 140000 человек в мире, это 1,3%, значит заболело почти 11млн человек. Если побочные эффекты у 0,1% вакцинированных то достаточно просто вакцинировать 110млн человек чтоб получить 140 000 смертей инвалидностей и тд. А если вакцинировать больше? А стоит ли вакцинация этого?
Ну и напоследок. До массовой вакцинации наблюдался спад эпидемий и болезней в тех регионах где происходило улучшение уровня жизни. Проще говоря там где антисанитария там и болели, что мы наблюдаем и ныне. После введения массовой вакцинации вообще ничего не поменялось.
Подробнее про это можете поискать фильм по вакцинации в СССР. (Был на Ютубе, сейчас названия не вспомню)
Ну и по поводу автоматического сканирования. Мой текущий проект содержит порядка полторы сотни различных сервисов, простыня из AddSingleton/AddTransient значительно перегружает конфигурацию. Я использую пометку атрибутом [SingletonService]/[TransientService], и сканированием регистрирую именно их. Очень удобно, и не надо волноваться забыл ты зарегестрировать или нет.
Более того, если сборку под проект делает другой человек, а мы их подключаем через нугет-репозиторий, то ему достаточно пометить атрибутом и его сервисы также будут зарегистрированы. Таким образом, если я использую какую либо зависимость, а она имеет еще 20-30 своих зависимостей, то простыню моих 150 сервисов расширять еще 30 не нужно.
Единственный момент, о сканировании надо помнить, потому как это не явная регистрация зависимостей.
Scrutor позволяет указать какие сборки сканировать. Но с другой стороны все это у нас не что иное как Back, и как показывает мой опыт, первые же клиенты подключившиеся к сервису заставят прогрузится все сборки, так что я не вижу особой разницы в моменте их загрузки, при первом вызове или при сканировании. Более того второй вариант мне кажется предпочтительней. Хотя конечно мой опыт не перекрывает все возможные сценарии.
Возможно https://github.com/khellang/Scrutor помог бы зарегестрировать работы определенные и в других подключенных сборках. Если конечно сами сборки не грузить ручками.
Какой в этом плюс? — ни слова.
Как сделать их тонкими, если они сейчас не такие? — ни слова.
Как сохранить их тонкими? — ни слова.
О чем заметка? Просто сообщить о нескольких проблемах?
Лично я зашел почитать ответы на те 4 вопроса которые Вы задали в начале. Но их почему-то нет.
С одной стороны статья перестанет складывать впечатление «обиженной девочки», с другой вы такую статью действительно сможете давать клиентам как сравнение продуктов.
Лично меня не покидает ощущение изложения в статье легкой формы истерики. И как клиент я сразу задумаюсь, а стоит ли связываться с компанией менеджмент которой впадает в истерику при столкновении с «черным» пиаром.
Мне вот интересен реальный пример, когда проект необходимо переводить на другую ORM.
Может скажете что на этапе проектирования не была учтена производительность ORM? Но тогда Вы просто не читали ТЗ.
Переход на другую ORM не праздный вопрос. Мне действительно интересна ситуация когда возникает необходимость перехода.
За все долгое время моего программирования пару раз сталкивался с ситуацией когда ORM просаживала производительность. Но каждый раз это были настолько нагруженные места, что и реляционная БД не справлялась с пиками, так что вопрос решался или построением очереди на запись в памяти или сбросом на диск с последующим переносом в БД. Объясните мне необходимость абстракции от ORM кроме желания прикрутить еще один паттерн.
Есть ситуация когда управляющий сервис, а с ним общается вся пачка из 200-т воркеров на постоянной основе, надо обновлять не останавливая работу. Мы поднимаем обновленный сервис и переводим на него работу всех воркеров.
Таже самая ситуация в обратную сторону, при переносе сервиса-воркера на другой сервер или виртуалку сервисы работающие с фермой должны отслеживать их перемещение. Если это один сервис, то еще ничего, а если их десяток?
У вас есть N ДЦ, в которых подняты идентичные системы, но обслуживают разные регионы. Например Европа-США-Азия, очень распространенный вариант размещения для увеличения отзывчивости. Предположим падает сервис или хостер уронил виртуалку или произошел непредвиденный сбой. Самый простой способ чтоб на время сбоя сервисы поднятые в других ДЦ перехватили работу павшего собрата, до момента его подъема.
А как Вы решаете проблему передачи данных на несколько сервисов, со сложным роутингом, размещением сервисов в региональных ДЦ? В случае постройки работы проекта на WebApi разворот потоков данных фермы достаточно не простая задача.