c# - ProtoBuf-net serialización IEnumerable<T>

silverlight

Question

Estoy tratando de usar ProtoBuf-NET en mi proyecto (en su mayoría es el proyecto Silverlight 4).

Tengo dificultades para serializar mis colecciones de modelos, todas ellas se definen así:

private List<T> _itemsSet;
public IEnumerable<T> TSet
{
    get {return _itemsSet;}
    set {_itemsSet = value == null ? new List<T>() : new List<T>(value);}
}
public void AddT(T item)
{
    //Do my logic here
    _itemsSet.Add(item);
}

Actualización: primero no puedo serializarlo: No serializer defined for type: System.Collections.Generic.IEnumerable 1 [MyType] `. En segundo lugar, creo que no podré desirializarlo en base a análisis de código fuente manual y protobuf-net.

1. ¿Hay alguna manera de extender protobuf-net para suministrar delegado al método externo Add en el atributo ProtoMemeber?
2. ¿Por qué usar ProtoMember(1, OverwriteList=true) no funciona? ¿No supone sobrescribir la colección y no debería importarle el método Add<T>() ? ¿Por qué simplemente no intenta establecer esta propiedad en T [] o en la List<T> o en cualquier conjunto asignable a IEnumerable<T> ?
3. ¿Hay alguna manera de proporcionar un mecanismo de reflexión personalizado para trabajar con campos privados en Silverlight, como: implementación: public interface IReflectable{ object GetValue(FieldInfo field); void SetValue(FieldInfo field, object value); } public interface IReflectable{ object GetValue(FieldInfo field); void SetValue(FieldInfo field, object value); } public interface IReflectable{ object GetValue(FieldInfo field); void SetValue(FieldInfo field, object value); } para trabajar con campos privados. Utilicé dicho enfoque para trabajar con campos privados con Db4o: http://community.versant.com/Forums/tabid/98/aft/10881/Default.aspx
4. ¿Qué opciones tengo excepto la creación de MyTypeCollection<T> : Collection<T> heredado MyTypeCollection<T> : Collection<T> ?

Answer 1

1. no al actual, no; el tipo expuesto debe tener (como mínimo) un método Add . Si bien no tengo ninguna objeción para investigar la posibilidad de un Add fuera del objeto en sí, esto es complicado ya que entonces estás mirando un objeto "primario" diferente (la secuencia frente al contenedor). Sin embargo; si su objeto primario implementó IEnumerable<T> (devolviendo _itemsSet.GetEnumerator() etc), entonces encontraría el Add automáticamente

2. No puedo ver el contexto aquí; sin embargo, sospecho que sin Add aún no está feliz de considerarlo una lista en primer lugar . Veo la forma en que vas con eso, sin embargo, y es quizás una forma en que podría razonar "Aquí puedo usar una List<T> )

3. No es algo que haya investigado, para ser honesto; entonces: no

4. El tipo expuesto en la propiedad debe, como mínimo: implementar IEnumerable (aunque IEnumerable<T> sería preferido), y exponer un método Add(T) . No tiene que ser Collection<T> / List<T> / etc - simplemente: debe (en la actualidad) tener algún mecanismo para agregar. IList<T> sería una opción pragmática, pero entiendo que no es exactamente lo que quieres.

Jonathan tiene razón en que un sustituto para la clase externa (lo que tiene _itemsSet , TSet y AddT ) también podría ser una opción.

Si la clase externa solo existe para tener la colección y el método add, entonces solo agregar : IEnumerable<T> y renombrar AddT para Add probablemente lo haga funcionar.

Answer 2

Estaba tratando de reducir las esquinas, y reutilizar mi modelo como un contrato de mensaje, pero este es realmente un enfoque equivocado. El camino a seguir es crear las clases especializadas y el convertidor de DTO para su modelo, de todos modos es bueno separar su modelo de los mensajes.

Sin embargo, debo criticar a Marc por agregar los atributos ProtoContract y ProtoMemeber que atraen a los usuarios a reutilizar su modelo atribuyéndolo.