Да, конечно. Решение о делегировании аутсорсеру какой-либо работы такое же компромиссное, как и большинство других архитектурных. In-house ограничен своим объемом и загруженностью, а аутсорс позволяет быстро масштабироваться. Получается, компромисс vendor lock-in против возможности быстро наращивать мощность дизайна/аналитик/разработки.
Для контроля за важными решениями, видимыми в ИТ-ландшафте, часто функционирует архитектурный совет/комитет/architecture board.
Архитектурные решения взаимозависимы, их можно представить в виде дерева. Решения ближе к корню/стволу несут больше последствий (в т.ч. их изменение дороже), чем тем, что ближе к листьям (периферийных). Кроме того, в терминах TOGAF архитектурные решения относятся к разным доменам (обыкновенно - Business, Data, Application, Technology). Разумно, что ответственность за архитектурные решения в разных TOGAF-доменах, на разных уровнях дерева архитектурных решений распределена в оргструктуре компании или делегирована.
Если специализация аутсорсера не просто кодировать по спецификации, а знать заказчика, постоянно вести у него аналитику и проектирование - то генерация, обоснование, принятие такого рода решений аутсорсером естественно.
У немцев, как известно, несколько имен. Поэтому термин given names, и правда, более корректен. Но есть основное имя, его обозначают подчёркиванием.
А вот пример с российским загранпаспортом плохой. В смысле, создаёт на практике неоднозначности и проблемы несоответствие имени и отчества с именем транслитерацией.
Написать заявление в ворде, экспорт в pdf, подписать ЭЦП, отправить по email, добавив в тексте заявления, что согласно ФЗ такому-то ЭЦП равносильна. Мне это как-то помогло при расторжении ОСАГО, когда было заградительное требование отправить по почте чуть ли не заверенную нотариально подпись под заявлением.
На самом деле в сообщении нет ничего сенсационного.
В энергоснабжении команда на ограничение энергопотребления до заданного уровня может прилететь от диспетчерской любому крупному потребителю (например, крупному заводу). Просто раньше это не касалось физлиц с их смешным потреблением. А теперь, видимо, физлица могут стать крупными потребителями.
Фактически такой подход — это ленивая загрузка многоязычного атрибута. Два раундтрипа для единичной сущности обычно дороже, чем JOIN или подзапросы. Но реализуемость для этого варианта не проверял.
Не ставлю под сомнение гибкость вашего фреймворка :)
Так расширяйте это комюнити, а не двигайтесть за толпой ;)
Ну это лозунг. Цель проекта как правило не в этом. Архитектурные решения, в том числе выбор технологий — часто связаны с рисками и/или компромиссами. Требования в боевых проектах разнятся и, быть может, linq2db в последующих проектах попадет в шорт-лист при выборе.
Огромное количество юнит тестов гарантируют что все это будет работать и через 10 лет.
Огромное количество тестов, увы, не гарантирует, что фреймворк будет поддерживаться и развиваться даже в течение ближайших трех лет.
Конечно, EF жесткий.
В статье специально рассмотрены только два самых популярных ORM на .NET. А для боевого проекта при выборе технологии сыграют роль не только гибкость, но и множество факторов, в том числе распространенность, размер комьюнити. https://goo.gl/2LP128
Таблицы или представления — нет разницы для использования с ORM, объема трафика, цены запросы и пр. Разве что, использовать хранимые (материализованные) view.
По поводу использования операторов и переопределенного Object.ToString() — спасибо, принято!
Все же методы ToString()/GetString() использовать приходиться, по нескольку перегрузок каждого с нужными параметрами (локаль, использовать ли и какой именно fallback process, поставщик форматирования). Причем две перегрузки ToString() нужны для корректного форматирования при подстановках.
У нас многоязычная строка и обвязка живут видимо потому, что существуют не сами по себе, а тесно интегрированы с другими инфраструктурными классами/библиотеками, включая ORM.
А по-поводу статьи (далее обращаюсь к ТС), извините, но вводить новый тип для строк и использовать что-то вроде
var fu = new MultiCulturalString(ru, "Шоколад Алина").SetLocalizedString(en, "Chocolate Alina");
На практике такой код практически не встречается, ведь ресурсы динамически подгружаются из упомянутого CustomizedResourceManager. Именно он нужен, например, для WinForms.
Возвращать null на неизвестную строку? Боже упаси!
Совершенно согласен. Это предположение введено в середине статьи, чтобы развить тему с IResourceFallbackProcess позже. А потом сказано, что пустоты на UI, конечно же, недопустимы.
Microsoft вводит требование локализуемости, т.е. отделение кода и ресурсов. Утверждается, что в локализуемом приложении не понадобится писать код для новых языков приложения. Наивные.
В вашем примере это явно не так. Возможно, именно для таких случаев, необходимо уметь размещать в сателлитных сборках (один из видов хранения ресурсов в .NET) стратегии по обработке конкретных ресурсов для разных языков.
SuperGenPass для не очень важных сайтов (инет-магазины, соцсети, форумы и т.д.) и индивидуальные ассоциативные фразы для важных (почта, банкинг) типа ,fyrbyuCjCnhfiysvUI (банкингСоСтрашнымUI).
Первый неудобен для мобильных. Русские фразы при английской раскладке еще хуже.
Не надо SAGA заглавными, это просто слово "сага ". Она же Long-running Action (LRA).
Да, конечно. Решение о делегировании аутсорсеру какой-либо работы такое же компромиссное, как и большинство других архитектурных. In-house ограничен своим объемом и загруженностью, а аутсорс позволяет быстро масштабироваться. Получается, компромисс vendor lock-in против возможности быстро наращивать мощность дизайна/аналитик/разработки.
Для контроля за важными решениями, видимыми в ИТ-ландшафте, часто функционирует архитектурный совет/комитет/architecture board.
Архитектурные решения взаимозависимы, их можно представить в виде дерева. Решения ближе к корню/стволу несут больше последствий (в т.ч. их изменение дороже), чем тем, что ближе к листьям (периферийных). Кроме того, в терминах TOGAF архитектурные решения относятся к разным доменам (обыкновенно - Business, Data, Application, Technology). Разумно, что ответственность за архитектурные решения в разных TOGAF-доменах, на разных уровнях дерева архитектурных решений распределена в оргструктуре компании или делегирована.
Если специализация аутсорсера не просто кодировать по спецификации, а знать заказчика, постоянно вести у него аналитику и проектирование - то генерация, обоснование, принятие такого рода решений аутсорсером естественно.
У немцев, как известно, несколько имен. Поэтому термин given names, и правда, более корректен. Но есть основное имя, его обозначают подчёркиванием.
А вот пример с российским загранпаспортом плохой. В смысле, создаёт на практике неоднозначности и проблемы несоответствие имени и отчества с именем транслитерацией.
Написать заявление в ворде, экспорт в pdf, подписать ЭЦП, отправить по email, добавив в тексте заявления, что согласно ФЗ такому-то ЭЦП равносильна. Мне это как-то помогло при расторжении ОСАГО, когда было заградительное требование отправить по почте чуть ли не заверенную нотариально подпись под заявлением.
Сегодня при входе отпечатком в приложение на Андроиде зацепил краем глаза, что "... вы даете согласие на обработку биометрических..."
Вроде такую хитрость здесь еще не обсуждали?
Версия 6.26 из Galaxy Store.
На самом деле в сообщении нет ничего сенсационного.
В энергоснабжении команда на ограничение энергопотребления до заданного уровня может прилететь от диспетчерской любому крупному потребителю (например, крупному заводу). Просто раньше это не касалось физлиц с их смешным потреблением. А теперь, видимо, физлица могут стать крупными потребителями.
"Портативная цель компиляции" — плохо
Фактически такой подход — это ленивая загрузка многоязычного атрибута. Два раундтрипа для единичной сущности обычно дороже, чем JOIN или подзапросы. Но реализуемость для этого варианта не проверял.
Не ставлю под сомнение гибкость вашего фреймворка :)
Конечно, EF жесткий.
В статье специально рассмотрены только два самых популярных ORM на .NET. А для боевого проекта при выборе технологии сыграют роль не только гибкость, но и множество факторов, в том числе распространенность, размер комьюнити. https://goo.gl/2LP128
Таблицы или представления — нет разницы для использования с ORM, объема трафика, цены запросы и пр. Разве что, использовать хранимые (материализованные) view.
Порт ICU Messages найден на гитхабе: https://github.com/jeffijoe/messageformat.net
По поводу использования операторов и переопределенного
Object.ToString()— спасибо, принято!Все же методы
ToString()/GetString()использовать приходиться, по нескольку перегрузок каждого с нужными параметрами (локаль, использовать ли и какой именно fallback process, поставщик форматирования). Причем две перегрузкиToString()нужны для корректного форматирования при подстановках.Интересно, а какие именно методы "победили"?
У нас многоязычная строка и обвязка живут видимо потому, что существуют не сами по себе, а тесно интегрированы с другими инфраструктурными классами/библиотеками, включая ORM.
Поясню. Есть две задачи:
GetString(...).На практике такой код практически не встречается, ведь ресурсы динамически подгружаются из упомянутого
CustomizedResourceManager. Именно он нужен, например, для WinForms.Совершенно согласен. Это предположение введено в середине статьи, чтобы развить тему с
IResourceFallbackProcessпозже. А потом сказано, что пустоты на UI, конечно же, недопустимы.Сейчас никак — стандартных средств нет.
Но и случаев таких пока не было.
Хороший вопрос.
Microsoft вводит требование локализуемости, т.е. отделение кода и ресурсов. Утверждается, что в локализуемом приложении не понадобится писать код для новых языков приложения. Наивные.
В вашем примере это явно не так. Возможно, именно для таких случаев, необходимо уметь размещать в сателлитных сборках (один из видов хранения ресурсов в .NET) стратегии по обработке конкретных ресурсов для разных языков.
,fyrbyuCjCnhfiysvUI(банкингСоСтрашнымUI).Первый неудобен для мобильных. Русские фразы при английской раскладке еще хуже.