First of all, please see my answer. I am not going to get into the whole topic, by the reasons I explained in this comment. I'll only try to give you some notes which might help you to pay attention for certain aspects of the topic.
First of all, I would note that the
SerializeableAttribute
is not the best example of the benefits of the attributes. The related serialization mechanism is morally already obsolete, but technically it is still needed. There is much smarter mechanism, which is more flexible and the easiest to use:
data contracts:
http://msdn.microsoft.com/en-us/library/ms733127.aspx[
^].
The big practical problem is that this mechanism is available .NET FCL only for XML and JSON based serialization. It does not cover binary and SOAP. I've even authored an alternative mechanism using the same idea, and implementation of serialization with good performance requires the use of
System.Reflection.Emit
, which is really hard to debug and requires deep understanding of IL. (Such techniques are used because serialization is slow, so serialization code is pre-generated to be reusable.)
So, my notes of the attributes will be more related to data contracts, and a bit less to
SerializeableAttribute
. It's important to understand that attributes merely adds some
metadata to code. In other words, they don't effect "usual" behavior of assemblies, types and members. They only statically provide some information which can be used in the code using reflection. Say, an attribute can tell this code (serializer, in this case), what to serialize and what not. What if gives us? Such features as 1)
non-intrusive approach, 2)
separation of concerns,
loose coupling.
In other words, when you add a new attribute, you change nothing, you are adding something which cannot change already existing functionality. You use the types normally, as if the attributes did not exist. And only the code using them, well… use them, for example, the code of the serializer. One alternative is using the serialization interface. It is also a way to separate concerns, but not that clearly. If you add an interface in base type list, you will immediately get a compilation error (unless the interface is completely empty), so it will force your to write implementation, which could be a lot of bothering. With attributes, it cannot happen (if only the attribute target is allows using it at the point, there are no multiple attributes of a given type if the attribute types allows that). At the same time, interface is much faster (that's why serializers generates serialization assemblies at runtime, as I explained above).
See also:
http://en.wikipedia.org/wiki/Separation_of_concerns[
^],
http://en.wikipedia.org/wiki/Loose_coupling[
^].
—SA