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