Десериализуйте объект в блок, который теперь подписывается и имеющий версию

Из шаблона ComponentA visitor проще всего сделать, если вы ожидаете значение для привязки visitor в дочерних компонентах, - добавить проверку *ngIf.


Это делает достоверную проверку значения visitors.length, которое будет оцениваться как false, пока сервисный вызов не вернет значение.

Также я бы порекомендовал вам переместить вызов службы в eventsService.view в ngOnInit из ComponentA и выйти из конструктора. Это также облегчает тестирование ComponentA.


Затем в дочернем компоненте для app-visitor

Из предыдущего ответа значение @Input () всегда неопределено

Это будет инициализироваться в ngOnInit, а не в конструкторе. ( Ознакомьтесь также с документацией Angular Life Cycle Hooks . )

blockquote>

Ваш код с использованием OnInit

import { Component, Input, OnInit } from '@angular/core';

@Component({
    selector: 'app-visitor-component',
    templateUrl: ''
})
export class ComponentAppVisitor implements OnInit {

    @Input() visitors: IVisitor[];
    constructor() {
    }

    ngOnInit() {
        console.log(this.visitors);
    }
}

9
задан Mephisztoe 23 April 2009 в 08:11
поделиться

3 ответа

Вы можете попробовать , используя суррогат сериализации, но без чего-то, что мы можем воспроизвести, будет трудно дать достойный ответ.

Проблема, однако, заключается в том, что BinaryFormatter просто очень и очень хрупок, когда речь идет о таких вещах, как сборки. Черт возьми, он достаточно хрупкий, даже внутри сборки .

Звучит так, как будто TreeViewData основана на дереве, поэтому мне интересно, был ли xml лучше (т.е. больше версии терпимо) вариант. Если речь идет об эффективности, существуют пользовательские двоичные форматы (например, protobuf-net ), которые предлагают высокопроизводительную переносимую двоичную сериализацию, устойчивую к версии. Если ваши данные уже сериализованы ... Интересно, может быть, пришло время изменить трек? Попробуйте использовать старую сборку для десериализации данных и переключитесь на более надежную стратегию сериализации.

3
ответ дан 4 December 2019 в 13:05
поделиться

Для решения этой проблемы можно использовать SerializationBinder :

private class WeakToStrongNameUpgradeBinder : SerializationBinder
{
    public override Type BindToType(string assemblyName, string typeName)
    {
        try 
        {
            //Get the name of the assembly, ignoring versions and public keys.
            string shortAssemblyName = assemblyName.Split(',')[0];
            var assembly = Assembly.Load(shortAssemblyName);
            var type = assembly.GetType(typeName);
            return type;
        }
        catch (Exception)
        {
            //Revert to default binding behaviour.
            return null;
        }
    }
}

Затем

var formatter = new BinaryFormatter();
formatter.Binder = new WeakToStrongNameUpgradeBinder();

Вуаля, ваши старые сериализованные объекты могут быть десериализованы с помощью этого средства форматирования. Если тип также изменился, вы можете использовать SerializationSurrogate для десериализации старых типов в ваши новые.

Как уже упоминалось, выполнение собственной сериализации вместо использования IFormatter это хорошая идея, поскольку у вас гораздо больше возможностей для управления версиями и сериализованным размером.

12
ответ дан 4 December 2019 в 13:05
поделиться

Я рекомендую никогда не использовать встроенные сериализации для постоянного хранилища. Всегда создавайте собственный код, если по какой-либо другой причине в будущем вам понадобится читать и записывать файлы в форматах на другом языке.

1
ответ дан 4 December 2019 в 13:05
поделиться
Другие вопросы по тегам:

Похожие вопросы: