Или конкректно с графами и диаграмами показывать почему GC без ручного решения задачи управления взаимосвязями не способен обеспечить работу взаимосвязей по правилам ООП.
Речь не шла о том плох или хорош WCF а о целесообразности его использования в наше время.
Внутри корпоративного сектора есть задачи где использовать его вполне себе рационально. Просто потому что у него есть свои плюшки в виде поддержки кучи транспортов, типов сериализации, авторизации и прочее.
Например в .netcore максимум что вы можете сделать, так это сгенерировать WCF клиент.
И даже при этом далеко не все в нем поддерживается, но для того чтобы запилить полную поддержку — нужно громадное количество кода.
WCF изрядно громоздкий и не отвечает потребностям современного рынка, да и существует он только в мире .NET и то не в core.
Да, он громоздкий, но вот по поводу потребности — не согласен. Тут надо понимать что WCF — это SOAP, который описывается через wsdl. И в net core вы можете сгенерировать клиента к любому SOAP сервису не только WCF. Не обижайте клуб любителей java с их спрингом и прочими плюшками. Нельзя просто так взять и похоронить хороший протокол (по крайней мере для корпоративного сектора).
Какое то у вас слишком категоричное мышление. А вы не думали, что у каждой технологии есть как преимущества, так и недостатки. Я так понимаю, что в SOAP вы видите одни недостатки. Но их и в REST порядком. Это если не привязываться к .Net в принципе. Да, для многих вещей, особенно публичных REST и .NET Standard отлично подходят, но есть и много других — для которых SOAP и WCF вполне себе хорошее решение.
PS Я вполне себе представляю как недостатки WCF так и преимущества (по крайней мере для меня), то же самое относится и к REST. Но ваш ответ выглядит весьма хамским.
Я к тому, что перед применением конфигурации вам обычный publish сделает еще и сборку проекта и еще много других ненужных вам вещей. А хочется, чтобы один проект, который собирается под CI и пакуется потом в артефакты можно было задеплоить на любую среду окружения будь то prod/qa/dev без повторной компиляции проекта. Поэтому и говорю что трансформацию конфигурации лучше держать подальше от процесса сборки. Если брать тот же .Net Core, даже трансформации не применяются все конфиги накатываются скопом, а потом в зависимости от окружения берутся подходящие значения либо из базового конфига, либо из конфига окружения. Что не исключает возможность их получения из других источников подробнее тут
Замечу только, что есть техники, позволяющие шифровать куски web.config'а.
Сталкивался я с такими техниками, больше не хочется.
А как вы все это собираете? Вы добавили в проект несколько конфигураций сборки. В данном случае у вас конкретная трансформация применяется в момент сборки проекта, но это же очевидно плохое решение. Конечный вид конфигурации должен зависеть от того в каком окружении запускается приложение, либо вобще от него не зависеть.
В вашем случае имхо трансформация конфига должна применяться не в момент сборки, а в момент публикации.
Так же непонятно как вы в своем решении прячете продакшн конфиг, в котором могут содержаться боевые логины/пароли и т.д. если все это зашито в релизную трансформацию, то это тоже решение не очень.
Как выше заметили для решения таких проблем используются либо переменные окружением, либо сервисы которые в зависимости от 1 переменной окружения (dev|stage|prod) выдаст вам актуальную конфигурацию для приложения
по поводу LogEvent недавно прикрутили в нлог structured logging, хотя я все равно поклонник Serilogа
Потому что его относительно легко подобрать при перехвате достаточно большого количества сообщений и расшифровывать все подряд. В данном варианте у каждой сессии будет свой ключ для блочного шифрования. Подобрав SIGNATURE_KEY можно будет расшифровать публичный ключ которым обмениваются сервера, а потом еще ведь необходимо как то расшифровать содержимое. В общем задача по дешифровке усложнится во много много раз
Мы писали-писали на .Net-стеке с MS SQL Server, а потом ВНЕЗАПНО осознали, что нам нужен LAMP
Увы, так бывает, к примеру на одной из предыдущих работ внезапно захотели хранить кредитные карты пользователей, что влечет за собой сертификацию по PCI DSS и отдельную изолированную базу данных.
Т.к. все писали на Net-стеке с MS SQL Server то и выбор был соответствующий. Но к моменту релиза внезапно! оказалось, что лицензий нет и необходимо переехать на PostgreSQL. И вот черт его знает баловство это или нет =(
Есть несколько воронок:
1 Налоги (на продажу товаров и производство)
2 Разница между выплачиваемой страховкой и стоимостью корабля (особенно учитывая что страховка платится только за корабль, а не за установленные в него модули стоимость которых может быть намного больше стоимости корабля)
3 Оплата прав собственности на систему 3
4 Оплата некоторых модулей устанавливаемых на POSах (Player Owned Structures) таких как циножаба (не позволяет вражеским кораблям запрыгивать в систему по циномаяку)
5. Оплата производственных линий
6 Оплата улучшений клонов
Первый шаг по превращению
мешков с костямилюдей в батарейки!Давайте, было бы интересно увидеть.
Внутри корпоративного сектора есть задачи где использовать его вполне себе рационально. Просто потому что у него есть свои плюшки в виде поддержки кучи транспортов, типов сериализации, авторизации и прочее.
И даже при этом далеко не все в нем поддерживается, но для того чтобы запилить полную поддержку — нужно громадное количество кода.
Да, он громоздкий, но вот по поводу потребности — не согласен. Тут надо понимать что WCF — это SOAP, который описывается через wsdl. И в net core вы можете сгенерировать клиента к любому SOAP сервису не только WCF. Не обижайте клуб любителей java с их спрингом и прочими плюшками. Нельзя просто так взять и похоронить хороший протокол (по крайней мере для корпоративного сектора).
PS Я вполне себе представляю как недостатки WCF так и преимущества (по крайней мере для меня), то же самое относится и к REST. Но ваш ответ выглядит весьма хамским.
Сталкивался я с такими техниками, больше не хочется.
В вашем случае имхо трансформация конфига должна применяться не в момент сборки, а в момент публикации.
Так же непонятно как вы в своем решении прячете продакшн конфиг, в котором могут содержаться боевые логины/пароли и т.д. если все это зашито в релизную трансформацию, то это тоже решение не очень.
Как выше заметили для решения таких проблем используются либо переменные окружением, либо сервисы которые в зависимости от 1 переменной окружения (dev|stage|prod) выдаст вам актуальную конфигурацию для приложения
по поводу LogEvent недавно прикрутили в нлог structured logging, хотя я все равно поклонник Serilogа
Но это конечно восхитительно в качестве среды разработки под .Net использовать IDE написанную на Java
Увы, так бывает, к примеру на одной из предыдущих работ внезапно захотели хранить кредитные карты пользователей, что влечет за собой сертификацию по PCI DSS и отдельную изолированную базу данных.
Т.к. все писали на Net-стеке с MS SQL Server то и выбор был соответствующий. Но к моменту релиза внезапно! оказалось, что лицензий нет и необходимо переехать на PostgreSQL. И вот черт его знает баловство это или нет =(
Ну мы же в России живем. Это же крипто про, какие открытые алгоритмы и технологии?
Не забудьте, что номер каждого токена должен быть вписан в пасспорт чтобы все знали кто есть кто
1 Налоги (на продажу товаров и производство)
2 Разница между выплачиваемой страховкой и стоимостью корабля (особенно учитывая что страховка платится только за корабль, а не за установленные в него модули стоимость которых может быть намного больше стоимости корабля)
3 Оплата прав собственности на систему 3
4 Оплата некоторых модулей устанавливаемых на POSах (Player Owned Structures) таких как циножаба (не позволяет вражеским кораблям запрыгивать в систему по циномаяку)
5. Оплата производственных линий
6 Оплата улучшений клонов