Я скучаю по дням удаленного взаимодействия .Net, когда я мог просто отправить объект по проводу, и он работал бы с обеих сторон среднего слоя без особой работы. И вот почему:
Мне дали задание. Я создаю уровень логики / абстракции данных (глупое соответствие PCI), чтобы мы могли перемещать наши серверы баз данных из корпоративной сети в защищенную сеть. Я сделал такой проект один раз под .Net 2.0 с удаленным доступом. Я построил объект на уровне промежуточного программного обеспечения и отправил этот объект клиенту, и у клиента был мой объект .Net для работы. Но WCF требует сериализации, чтобы иметь возможность отправлять вещи вверх и вниз по каналу, и сериализация отбирает у меня причудливые методы, которые делают невероятные вещи с полями, которые у меня есть.
Я придумал две разные стратегии, чтобы обойти это: (1) переместить методы из самого класса в статический служебный класс и (2) «десериализовать» данные на стороне клиента и перестроить собственный объект с данными из сериализованного объекта.
nativeObject.Name = serializedObject.Name;
Недостаток второго метода заключается в том, что мне необходимо повторно сериализовать объект, прежде чем я смогу отправить его обратно на уровень промежуточного программного обеспечения.
serializedObject.Name = nativeObject.Name;
Оба метода работают, но из-за всей беспорядочной сериализации, которую вызывает средний уровень, написание объектов занимает гораздо больше времени, чем следовало бы. Я бы вернулся к .Net Remoting, но архитектор говорит, что он хочет, чтобы этот слой абстракции создавался в WCF, потому что (мои слова, а не его) он новый и сексуальный.
Так как же работать с нативными объектами .Net по обе стороны соединения WCF ... без написания 1000 строк связующего кода.