Лямбды, закрытые переменные, отображаемые классы, сериализуемость и уровни распространенности - PullRequest
2 голосов
/ 19 января 2011

Я реализовал уровень распространенности для Compact Framework (включая сериализатор, подобный BinaryFormatter). Я хотел бы иметь возможность сериализовать сгенерированные компилятором классы, которые являются результатом таких вещей, как лямбда-выражения и итераторы, где это необходимо, чтобы, если (например) лямбда-выражение и его закрытые переменные (то есть экземпляр класса отображения) добавляется к событию в сериализуемом объекте, и все закрытые переменные сериализуются, тогда результирующий граф объектов по-прежнему полностью сериализуем.

Допустимо, если экземпляры этих классов могут быть десериализованы только с помощью точно такой же сборки двоичных файлов, из которых они были сериализованы - уровень распространенности в основном предназначен для обеспечения устойчивости в случае неожиданного завершения приложения ( сбой питания и перезагрузка устройства - это разные возможности), и ожидается, что поток сериализованных данных не будет ни напрямую, ни обратно совместим, ни даже совместим между двумя компиляциями одного и того же исходного кода - все последствия будут отправлены до сервер, когда мы в следующий раз поговорим с ним, и мы не будем обновляться, пока он отключен.

Разумно ли в этом ограниченном контексте для моего средства форматирования обрабатывать эти сгенерированные компилятором классы, как если бы они были сериализуемыми? Единственная альтернатива, которую я вижу, состоит в том, чтобы вручную реализовать те модели паттернов, поддерживаемых компилятором, везде, где сериализуемость является проблемой, с последствиями, варьирующимися от слишком многословного до почти нечитаемого.

1 Ответ

2 голосов
/ 19 января 2011

Я понимаю, к чему вы клоните, но, по моему опыту, гораздо лучше сконцентрироваться на сериализации данных и управлять долговечностью, откатываясь назад / вперед до известного состояния, возможно, используя что-токак локальная очередь CQRS или какой-то другой способ хранения «как вы туда попали».

Относительно конкретного вопроса, в узком объеме вопроса (работает только в той же сборкеи т.д.) Я думаю, , что все должно быть в порядке, но это во многом зависит от того, что захвачено в этих переменных не имеет разумной сериализации - то есть что-то вродеЭлемент пользовательского интерфейса (легко случайно захваченный невидимым this), который невозможно восстановить (дескрипторы операционной системы и т. Д.).Если это изолированные данные (под этим я подразумеваю: график - это просто данные из вашего собственного кода - без неуправляемых зависимостей), тогда я предполагаю, что должно быть в порядке.

Другая проблемав том, что CF не хватает большей силы отражения, доступной в полной структуре, что может сделать это немного более неловким, чем в обычной структуре (например, GetUninitializedObject).Возможно, выполнимо, но немного больше работы.

...