Это нормально, что разные части системы могут быть построены с использованием различных технологических стеков.Поскольку эти части должны иметь возможность общаться друг с другом (так или иначе), важно указать контракты между подсистемами.
Очень важно думать первым об этих контрактах, так как эти части вашей системы (подсистемы) могут (и, без сомнения, будут) подвергаться изменениям (в связи с развитием их бизнес-логики, исправлением ошибок и т. д.).
При наличии этихКонтракты, которые вы позволяете подсистемам быть изменены независимо, не влияя на всех их "клиентов" (другие подсистемы).В противном случае вы получите синдром «Мне нужно это исправить, но он может повлиять на множество мест, о которых я даже не знаю».
Что ж, как только вы заключите контракт, вы сможете делать все, что захотитев данной подсистеме, которая просто рай!:)
Это означает, что вместо "извлечения рубинового хеша" вы обычно хотите определить независимый от платформы контракт , который будет представлен как аспект в терминахбизнес логика вашего приложения .Этот контракт затем может быть использован любой другой подсистемой, написанной по любой технологии.
Это также означает, что вместо простой передачи данных между подсистемами вы хотите передать некоторые объекты .Эти объекты не только содержат данные, которые вы хотите передать, но также описывают эти данные, придают им некоторое значение.Под этим «описанием» я подразумеваю тип объекта, имена свойств и т. Д.Знаете, объекты являются информативными.
Вы можете объявить контракт для вашей подсистемы ruby, сказав: «Я принимаю эти запросы и возвращаю эти результаты».И запрос (метод), и результат (объект) должны быть сформулированы в терминах бизнес-логики указанной подсистемы.Например, GetProducts contract должен, вероятно, возвращать список Product объектов, а не несколько бессмысленных "рубиновых хэшей".Таким образом, все потребители будут знать, что такое контракт и чего ожидать.
Тогда вы можете сделать его стандартом, заявив, что «между подсистемами все передаваемые объекты сериализуются в JSON (или XML)», что болеечем тривиальный в Ruby, C # или любом другом языке, а также действительно независимый от платформы.
Поэтому, возвращаясь к вашему вопросу, у вас обычно просто нет такой проблемы в вашей жизни, как перевод типов ruby в типы .NETиспользование некоторых библиотек с ошибками или подобные сумасшедшие вещи :)
Простое определение контрактов и стандартизация транспорта (JSON?) помогут вам многими способами, начиная от избавления от этой проблемы и до самого конца.благодаря чистой и легко обслуживаемой системе.