views:

532

answers:

3

XML Serialization from MSDN:

Serializes and deserializes objects into and from XML documents. The XmlSerializer enables you to control how objects are encoded into XML.

Reflection from MSDN

Reflection provides objects (of type Type) that encapsulate assemblies, modules and types. You can use reflection to dynamically create an instance of a type, bind the type to an existing object, or get the type from an existing object and invoke its methods or access its fields and properties. If you are using attributes in your code, Reflection enables you to access them.

As far as my understanding goes, I could create objects in run time using XML Serialization? In other words, let's say I have a database, I could define my "classes" or "objects" in couple of tables. I could then get the XML for the object's data and then create the object at run-time.

I could also already have those objects compiled as libraries readily available and then use Reflection to access it's functions.

From your understanding, which one of these two concepts would grant the most flexibility while sacrificing the least performance? Bonus points if you can provide a detailed explanation with considerations and perhaps a sample of code.

+1  A: 

Serialization and Reflection are not mutually exclusive. You could definitely serialize and deserialize an object and then subsequently modify it using Reflection.

Serialization

Serialization is simply the concept of taking a 'snapshot' of an object's state so that you can potentially restore that snapshot at a later time.

If you wish to store objects in a persistent store, serialization is a good option if you don't need to be able to query after particular values.

Note that there are at least two different types of serialization:

  • XML Serialization, that represents an object as XML. Since it is XML, this representation is (in theory at least) human-readable and interoperable.
  • Binary serialization, that simply stores and reads an object as an array of bytes. This representation is proprietary and not human-readable.

Reflection

Reflection is the ability to use object metadata to manipulate an object. You could, for example, decide that you want to assign the string "Foo" to all writable string properties of a given object, irrespective of the type of object.

This is mostly interesting when the type of object is not known at design time.

Mark Seemann
A: 

To use deserialize an object you need to know the type you want to deserialize it into. So you can't just create you objects from xml without having its type defined in an assembly.

What you can do is to store xml in your database that represents serialized objects. You could then load the xml from the database and deserialize it into object instances as needed. The source of the xml need not be a serialized object, so you can create it manually if you need.

Using reflection would be a different situation. With reflection you could take an object and get a list of the method and properties available on the object. You could then write code that worked dynamically with your objects regardless of which type they implement. The problem with this approach is that the code is clumsy to write and read, and it is very easy to introduce errors that are only visible at run time. On top of that the code will run slowly due to the overhead introduced by using reflection.

Instead of using reflection I would have my objects implement some well known interfaces that I could cast them to. That would allow my code to be type-safe and I could avoid the hassle of reflection. The code would also run much faster and be more readable.

Rune Grimstad
A: 

You cannot create new types on the fly using neither XML serialization nor reflection. These techniques only applies to existing types. If you need to create new types at runtime you will have to use another approach. However, generating types of the fly is of limited usefulness since you can only use reflection to access these types. Using the dynamic runtime in the next major release of .NET will give you more options for creating and using dynamic types.

XML serialization is for serializing objects to and from a well known format (XML). Reflection is much more general and enables you to inspect type information at runtime and manipulate objects without knowing their type at compile time. You can also do serialization using reflection, but it is much more cumbersome compared to XML serialization.

Martin Liversage
It's not true that you cannot create new types on the fly with Reflection. Take a look at Reflection Emit.
Mark Seemann
@Mark Seemann. The `System.Reflection.Emit` namespace was what I was thinking of when I wrote "another approach". I don't consider this part of "normal" reflection, but rather a framework for compilers and code generators to generate code as opposed to reflecting on code. Your definition of "reflection" may of course be different.
Martin Liversage