Let's suppose I have to serialize an object of a class Car in levels e.g. Internal and Public. Some of the properties in the Public level should not be serialized as they are internal.
At this moment the 'easiest' way I can think of to achieve this is by using inheritance:
class CarPublic {
public int PropX {get;set}
}
class CarInternal: CarPublic {
public string PropY {get;set}
}
Then I could
object ToSerialize() {
CarInternal car = GetCar();
if( level == Level.Public ) {
return car as CarPublic;
} else {
return car;
}
}
The result of the ToSerialize() is taken by a framework (I don't have
control over) and serialized to JSON or XML.
I omitted the XML serialization attributes for simplicity.
This feels like a hack and hacks take you only so far. Is there better way (ways?) to achieve this?
I think its clear by now, but I would like to avoid writing my own serialization methods for JSON and XML.
Thanks in advance
Tymek
==EDIT
To clarify, I want to be able to serialize multiple levels:
class Car0 {
public int PropA {get;set}
}
class Car1: Car0 {
public string PropB {get;set}
}
class Car2: Car1 {
public int PropC {get;set}
}
class Car3: Car2 {
public string PropD {get;set}
}
and
object ToSerialize( Level level ) {
Car3 car = GetCar();
switch( level ) {
case Level.Zero: return car as Car0;
case Level.One: return car as Car1;
case Level.Two: return car as Car3;
case Level.Three: return car as Car4;
}
return null;
}
== Chosen approach
I marked Marc Gravell's answer as the answer, as it provides the generic information of how C# and it's 'standard' components support what I asked for.
However I think the best approach for my problem is to use proxy classes as shown above and
have the class being serialized in this multi-level pattern with methods like shown below.
public interface ICar {
Car0 As0();
Car1 As1();
Car2 As2();
Car3 As3();
...
}
This allows keeping the Car0..3 classes very simple, with only properties, to maintain and understand.
This depends a lot on what serialization framework you are using. You mention xml and json - well, the first thing to note is that you can just decorate with:
[XmlIgnore]
public int PropX {get;set;}
or
[ScriptIgnore]
public int PropX {get;set;}
which XmlSerializer and JavascriptSerializer will respond to. If you need to make the decision on a per-instance basis, there is the ShouldSerialize* and *Specified patterns:
public bool ShouldSerializePropX() {
// return true to serialize, false to omit
}
The above is a name-based pattern, that is used by XmlSerializer and others; it has a twin:
[XmlIgnore, Browsable(false)]
public bool PropXSpecified {
get { /* return true to serialize, false to omit */ }
set { /* can just drop this value - don't need to assign */ }
}
You don't need to do anything to wire them up - they work automatically.
Different serializers allow different patterns.
In addition, sometimes you can add things like [XmlIgnore] at runtime - for example via XmlAttributeOverrides, or the equivalent for any given serializer.
You could decorate your Internal properties with a custom attribute indicating that they should be included (or ignored depending on your requirements) and then in your ToSerialize check the attribute.
[AttributeUsage(AttributeTargets.Property, AllowMultiple = false, Inherited = true)]
public class ShouldSerializeAttribute : Attribute { }
Then your resulting class definition would look like:
class Car
{
[ShouldSerialize]
public int PropX {get;set}
// This property won't be serialized because it is internal
public int PropY { get; set; }
}
You ToSerialize would look something like:
object ToSerialize()
{
Car car = GetCar();
foreach(PropertyInfo propInfo in car.GetType().GetProperties())
{
if(ShouldSerialize(propInfo))
{
return car;
}
}
}
Where ShouldSerialize could look like:
internal bool ShouldSerialize(PropertyInfo propInfo)
{
return propInfo.GetCustomAttributes(typeof(ShouldSerializeAttribute), true).FirstOrDefault() != null;
}
UPDATE
Based on #Bill's insight in the comments. If you're looking to only serialize public attributes when level is Level.Public you can achieve that effect by reflecting on the type's properties using the BindingFlags.DeclaredOnly flag:
foreach(PropertyInfo propInfo in car.GetType().GetProperties(BindingFlags.DeclaredOnly))
This should return a list of the properties declared only by the current instance of car.
Related
I have classes that might or might not change their name (and members) during development. My classes are used (in most cases) like enums, but I couldn't use enums because I needed slightly more functionality. Since classes (obviously) don't have an Integer representing them under the surface I need to create some solution for having similar functionality. In other words, I want for each class to be represented by an Integer (or some other unique identifier).
I've created this attribute:
public class IdAttribute : Attribute
{
private int id = -1;
public IdAttribute(int index)
{
this.id = index;
}
public int Id
{
get
{
return id;
}
}
}
And I'm using it as following:
[Id(0)]
public class Hello: Core { }
[Id(1)]
public class Bye: Core { }
As you can see it's quite error prone, since I don't want any class to have the same Id. And thus, optimally I want an automatic generated id, but I don't want it to change if I ever change anything regarding the class, for example the class name or its members.
What's the best way to achieve this?
(I know that in Java, that once you make a class Serializable, you'll get an automatically generated id (is there something like this in C#?).)
EDIT:
The reason I "couldn't" just use enums is because of (mainly) convenience. I have classes which exposes fields in an editor. And in this editor I can select only the appropriate "enums", in some cases only enums which inherits from "Core" will be displayed and in other cases they might inherit from "Tools" or some other class. I hope that cleared up a bit.
Not sure why you'd need to do this, but you could do the following:
[AttributeUsage(AttributeTargets.Class)]
public class IdAttribute:Attribute
{
public Guid Id { get; }
public IdAttribute(string id)
{
Id = new Guid(id);
}
}
And you'd use it like:
[IdAttribute("7d7952d1-86df-4e2e-b040-fed335aad775")]
public class SomeClass
{
//example, you'd obviously cache this
public Guid Id => GetType().GetCustomAttribute<IdAttribute>().Id;
//...
}
Do note, that Guids are not random. If you need a random id, then this isn't the solution. To generate a Guid read comments to your question.
You can handle that through your base class Core:
public abstract class Core
{
public Core()
{
Type myType = this.GetType();
object[] attrs = myType.GetCustomAttributes(typeof(IdAttribute), false);
IdAttribute attr = attrs?.OfType<IdAttribute>().FirstOrDefault();
int id = -1;
if (attr != null) id = attr.Id;
if (!reservedIdentities.ContainsKey(id))
{
reservedIdentities.Add(id, myType);
}
else
{
if (!reservedIdentities[id].Equals(myType))
throw new ArgumentException("Duplicate identities discovered.", nameof(id));
}
}
static Dictionary<int, Type> reservedIdentities = new Dictionary<int, Type>();
//...
}
I have 2 classes which are inherited in this manner
public class PartsParent
{
}
public class PartsCar : PartsParent
{
public int WheelRadius { get; set; }
public int Price { get; set; }
}
public class PartsBike : PartsParent
{
public int Length { get; set; }
public int Weight { get; set; }
public int Price { get; set; }
}
And i have a function that accepts the class PartsParent as parameter and how can i convert this as partsCar / as PartsBike inside the function and access properties like Price WheelRadius etc?
private int PriceCollection(PartsParent mainObject)
{
int _price=0;
mainObject.OfType(PartsCar).Price;// something similar??
return _price;
}
Well, you are trying to cast a parent type to a child type, that is not really possible, why ?
The answer is that the parent P you are trying to cast to child C1 can be actually and originally of type C2, so the cast would be invalid.
The best way to explain this is a phrase that I read somewhere here on stackoverflow
You can't cast a mammal into a dog - it might be a cat.
You can't cast a food into a sandwich - it might be a cheeseburger.
What you can do though to turn around this situation is something like this :
(mainObject is PartsCar) ? (PartsCar)mainObject : mainObject
Which is equivalent to :
mainObject as PartsCar
Then access mainObject's cast result using the null coalescing operator (because if as fails, the cast result will be null instead of throwing an Exception).
The generic method OfType<T> that you tried to use is an extension method that can be used with objects of type IEnumerable<T'> , which I guess is not your case.
The idea of inheritance is to group up what is common in a super class, and leave other specific details to sub-classes. So if a property, say Price, is excepted from all sub-classes, then it should be declared in the super class.
However, if you still want to use it this way, then what are you looking for is:
int _price = ((PartsCar)mainObject).Price;
However, what if the object was of some other class, say PartsGift that inherits from PartsParent, but does not have a price? Then it will crash.
You almost really need to check your design.
BTW, if you want to check if an object is really of a specific class, then you can use is.
int number = 1;
object numberObject = number;
bool isValid = numberObject is int; // true
isValid = numberObject is string; // false
You can use is keyword to check the type and as keyword to convert to the target child type as following.
if (mainObject is PartsCar)
{
var partscar = mainObject as PartsCar;
// Do logic related to car parts
}
else if (mainObject is PartsBike)
{
var partsbike = mainObject as PartsBike;
// Do logic related to bike parts.
}
It's possible if you separate uncommon properties your code into block:
if (mainObject is PartsCar)
{
//Seprated code for PartsCar
// WheelRadius...
//Price...
}
else if (mainObject.GetType() == typeof(PartsBike))
{
//Seprated code for PartsBike
//Length
//Weight
//Price
}
I have the following class
[ProtoContract(ImplicitFields = ImplicitFields.AllFields)]
public class Foo
{
public int foo { get; set; }
[ProtoIgnore]
public Bar bar { get; set; }
public int ToMD5Hash()
{
var md5 = MD5CryptoServiceProvider.Create();
using (MemoryStream ms = new MemoryStream())
{
Serializer.Serialize<Foo>(ms, this);
var hash = md5.ComputeHash(ms.ToArray());
return BitConverter.ToInt32(hash, 0);
}
}
}
But I am getting an exception when calling ToMD5Hash. It says No serializer defined for type: SomeNamespace.Bar even if the property is decorated with the ProtoIgnore attribute.
Note: If I remove ImplicitFields and use ProtoMember, the serialization works.
Am I doing something wrong?
You've told it to serialize the fields. The field is not decorated with [ProtoIgnore]. The property is, and there is no good way to equate fields to properties. The use of the term "fields" here is very specific and intentional: it doesn't mean "members" - it means "fields".
Options:
tell it to serialize public members, not fields
use a manually implemented property and mark the field with [ProtoIgnore]
mark the members manually
It would be nice if automatically implemented properties allowed the same syntax as field-like events, i.e.
[field:ProtoIgnore]
public int Foo {get;set;}
However, I'm pretty sure that this is not supported in the language.
I want to create a key value table in my database along the lines of
public class KeyValue {
public string Id { get; set; }
public dynamic Value {get; set; }
}
Using a slightly modified SqlProvider I have no problems getting CreateTable<KeyValue>() to generate varchar(1024) Id, varchar(max) Value.
I have no issues saving objects to it. The problem is when I load the objects
var content = dbConn.GetById<KeyValue>("about");
content.Value at this point is a string.
Looking at the database record, the text for value does not appear to store any type information.
Is there really anything I can do better other than manually invoking ServiceStack.Text and call deserialize with the appropriate type information?
I do not need absolute dynamic, my actual use case is for polymorphism with a base class instead of dynamic. So I don't really care what type Value is whether it's the base class, dynamic, object, etc. Regardless other than using the class
public class KeyValue {
public string Id { get; set; }
public MySpecificChildType Value {get; set; }
}
I haven't been able to get anything other than a string back for Value. Can I tell OrmLite to serialize the type information to be able to correctly deserialize my objects or do I just have to do it manually?
Edit: some further information. OrmLite is using the Jsv serializer defined by ServiceStack.Text.TypeSerializer and is in no way pluggable in the BSD version. If I add a Type property to my KeyValue class with the dynamic Value I can do
var value = content.Value as string;
MySpecificChildType strongType =
TypeSerializer.DeserializeFromString(content, content.Type);
I just really want a better way to do this, I really don't like an object of 1 type going into the db coming back out with a different type (string).
I haven't worked much with the JsvSerializer but with the JsonSerializer you can achieve this (in a few different ways) and as of ServiceStack 4.0.11 you can opt to use the JsonSerializer instead, see https://github.com/ServiceStack/ServiceStack/blob/master/release-notes.md#v4011-release-notes.
Example
public abstract class BaseClass {
//Used for second example of custom type lookup
public abstract string Type { get; set; }
}
public class ChildA : BaseClass {
//Used for second example of custom type lookup
public override string Type { get; set; }
public string PropA { get; set; }
}
And then in your init/bootstrap class you can configure the serializer to emit the type information needed for proper deserialization:
public class Bootstrapper {
public void Init() {
ServiceStack.Text.JsConfig.ExcludeTypeInfo = false;
ServiceStack.Text.JsConfig.IncludeTypeInfo = true;
}
}
If you wish to use something other that the default "__type" attribute that ServiceStack uses (if you for example want to have a friendly name identifying the type rather then namespace/assembly) you can also configure your own custom type lookup as such
public class Bootstrapper {
public void Init() {
ServiceStack.Text.JsConfig.ExcludeTypeInfo = false;
ServiceStack.Text.JsConfig.IncludeTypeInfo = true;
ServiceStack.Text.JsConfig.TypeAttr = "type";
ServiceStack.Text.JsConfig.TypeFinder = type =>
{
if ("CustomTypeName".Equals(type, StringComparison.OrdinalIgnoreCase))
{
return typeof(ChildA);
}
return typeof(BaseClass);
}
}
}
I'm trying to implement a class to access items of different types, in a similar way to database rows.
However, I have two different ideas in mind, and I don't know which one to choose:
Design 1
public enum ObjectTypeA
{
Undefined,
Integer,
Float
}
public class MyObjectA
{
private object val;
public ObjectTypeA Type
{
get;
private set;
}
public int Integer
{
get
{
if (Type != ObjectTypeA.Integer) throw new Exception();
return (int)val;
}
set
{
Type = ObjectTypeA.Integer;
val = value;
}
}
public float Float
{
get
{
if (Type != ObjectTypeA.Float) throw new Exception();
return (float)val;
}
set
{
Type = ObjectTypeA.Float;
val = value;
}
}
}
Less compile-time checks possible.
Can't use the is operator, GetType(), etc. (reinvents the type system).
Boxing and unboxing for value types.
Can be inherited by other classes (e.g. I can create a "named object" using inheritance).
Design 2
public abstract class MyObjectB
{
}
public class MyIntegerB : MyObjectB
{
public int Value
{
get;
set;
}
public MyIntegerB(int _value)
{
Value = _value;
}
}
public class MyFloatB : MyObjectB
{
public float Value
{
get;
set;
}
public MyFloatB(float _value)
{
Value = _value;
}
}
Shorter and simpler implementation.
Very verbose (casting) to use.
Performance is not critical, but it's still important, since most of the objects that are going to be stored are integers or floats, so boxing overhead matters.
The classes will just contain the values, not methods that depend on the type, etc. so it doesn't matter if the solution uses inheritance.
IMPORTANT: One of the requirements is that there may be two types that use the same underlying type (e.g. two classes derived from MyObjectB may use int as the Value), so using object or generics may not be possible.
Any suggestion about which design to use, or another different design?
EDIT:
The reason I don't like the second one is because it's very verbose to use:
MyObjectB objB = new MyIntegerB(12);
Console.WriteLine(((MyIntegerB)objB).Value);
And because I can't inherit it to create something like a "named object", so I have to attach MyObjectB to the class, and the usage is even more verbose.
I don't see why you wouldn't use generics here. More strongly: I don't see why you need this at all: It seems like Nullable<T> would cover all of your use cases very nicely. If not, implementing this generically is trivial:
public class ValueWrapper<T>
{
public T Value
{
get;
private set;
}
public Type WrappedType
{
get { return typeof(T); }
}
}
public MySpecialInt : ValueWrapper<int>
{
/* etc */
}
why not use generics?
public abstract class MyObjectB<T>
{
public T Value
{
get;
set;
}
public MyObjectB(T _value)
{
Value = _value;
}
}
you only need one class at this point. just instantiate it differently:
var myObj = new MyObjectB<Int>(1);
or
var myObj = new MyObjectB<Float>(0.012);
I know you mentioned not wanting to deal with boxing and unboxing, but I still think a Generic class would be your best bet here.
public class MyObject<T>
{
public MyObject(T t) {
Value = t;
}
public T Value { get; set; }
}
Edit:
One of the requirements is that there
may be two types that use the same
underlying type (e.g. two classes
derived from MyObjectB may use int as
the Value), so using object or
generics may not be possible.
That would only apply if you're extending the class. There's no problem if you wrap the class instead, i.e. create a MyObject<int> and access its Value property, rather than subclassing it.
Having said that, if you want to subclass a generic class, the subclass would also need to be a generic class.
Have you considered generics?
public class MyObjectA<T> {
public T Value {
get; set;
}
}
I've written a similar class that could hold either a single instance of ClassX or an array of ClassX. The trick was that it could change during runtime, so a generic wouldn't suffice, but I still wanted it strong-typed in all cases. It sounds like that's similar to what you're trying to accomplish here.
I chose the first option, and here's why: Wherever possible, I encapsulate complexity within a class to make the class easier to use. Classes should encapsulate away complexity from the caller, making calls to it more concise. If using MyObjectB makes your code more verbose, than I don't think that's the right answer.
if you need heterogeneous collections then this would do.
public enum ObjectTypeA
{
Undefined,
Integer,
Float
}
public class MyObjectA
{
public MyObjectA(object value) : this(value, InfereType(value))
{ }
public MyObjectA(object value, ObjectTypeA type)
{
Value = value;
Type = type;
}
public object Value { get; private set; }
public ObjectTypeA Type
{
get;
private set;
}
public T ValueAs<T>()
{
return (T)Value;
}
}
then use it like
List<MyObjectA> list = GetAllValues();
foreach (var item in list)
{
switch (item.WrappedType)
{
case MyObjecttypeA.Float:
float f = item.ValueAs<float>();
// do something with float
}
}