I've been programming in .Net for about 3 years now, and I've finally learned how to use custom attributes

Well, I've learned how to use them, but I'm still a bit unclear on when to use them. For example, in LLBlGen, the generated entities have properties like LLBLGenProIsInHierarchyOfType and LLBLGenProEntityTypeValue that seem like perfect candidates for attributes, yet they are properties...which makes me wonder

One of the things I have noticed about using custom attributes as opposed to just a normal property on a class is that the custom attributes are much clumsier to read (using reflection, having to check an array, etc...). Is this the reason LLBlGen doesn't use them in general?

Correct. To determine a value, which is set by an attribute, you indeed have to reflect, look up the attribute, and then interpret the set value. By reading a property it's much faster.

You then could cache the attribute values per type in an internal singleton, but I opted for a property which simply returns a constant generated into the code.

Rule of thumb: - if you need data about TYPES when you don't have instances around, use attributes - if you need data about INSTANCES, use a property/field.

Otis wrote:

Correct. To determine a value, which is set by an attribute, you indeed have to reflect, look up the attribute, and then interpret the set value. By reading a property it's much faster.

You then could cache the attribute values per type in an internal singleton, but I opted for a property which simply returns a constant generated into the code.

Rule of thumb: - if you need data about TYPES when you don't have instances around, use attributes - if you need data about INSTANCES, use a property/field.

I'm still a bit confused. Couldn't you use a shared (static?) property when you don't have instances around?

I know one of the arguments of using attributes over properties is that the properties will clutter up a class if you have a lot of them...but I don't know if this is a good argument because they really are "properties" of the class! Renaming them attributes so that they can be stuck outside the class definition seems like it would only be worth it if using the attributes was as easy as using the properties, which it doesn't appear to be.

And as for attributes, are there any common patterns out there for reading their values? I can come up with something obvious like:

Public Function GetAttributeValue(object as Object, attributeType as System.Type, propertyName as String) As Object
    Dim attributesInObject() as Attribute = object.GetType.GetAttributes(attributeType)
    If attributesInObject.count > 0 Then
        'reflectionUtils is just a class of reflection utilities. 
        'GetPropertyValue uses reflection to read a property and return its value.
        return reflectionUtils.GetPropertyValue(attributesInObject(0), propertyName)
    Else
        return Nothing
    End If
End Sub

but is there some way that all the AOP programmer types (or anyone that makes heavy use of attributes) do it that is more well thought out?

mikeg22 wrote:

Otis wrote:

Correct. To determine a value, which is set by an attribute, you indeed have to reflect, look up the attribute, and then interpret the set value. By reading a property it's much faster.

You then could cache the attribute values per type in an internal singleton, but I opted for a property which simply returns a constant generated into the code.

Rule of thumb: - if you need data about TYPES when you don't have instances around, use attributes - if you need data about INSTANCES, use a property/field.

I'm still a bit confused. Couldn't you use a shared (static?) property when you don't have instances around?

Technically, you could but it still would require an instance of the type, (statics share one instance behind the scenes). With attributes, you can reflect over types in an assembly without instantiating the type. This can have advantages, for example if the static usage of a member will instantiate static data.

One downside to static properties is that you can't use polymorphism: now I can call the properties you mentioned in the ormsupportclasses and get the info back. With static properties I couldn't.

I know one of the arguments of using attributes over properties is that the properties will clutter up a class if you have a lot of them...but I don't know if this is a good argument because they really are "properties" of the class! Renaming them attributes so that they can be stuck outside the class definition seems like it would only be worth it if using the attributes was as easy as using the properties, which it doesn't appear to be.

I don't think attributes and properties are interchangeable, only in very special cases.

And as for attributes, are there any common patterns out there for reading their values? I can come up with something obvious like:

Public Function GetAttributeValue(object as Object, attributeType as System.Type, propertyName as String) As Object
    Dim attributesInObject() as Attribute = object.GetType.GetAttributes(attributeType)
    If attributesInObject.count > 0 Then
        'reflectionUtils is just a class of reflection utilities. 
        'GetPropertyValue uses reflection to read a property and return its value.
        return reflectionUtils.GetPropertyValue(attributesInObject(0), propertyName)
    Else
        return Nothing
    End If
End Sub

Attributes have a type as well, so you could cast to that specific attribute type (you can also search for an attribute of a given type if I remember correctly, it's been a while, I have to look it up) and access the property directly

but is there some way that all the AOP programmer types (or anyone that makes heavy use of attributes) do it that is more well thought out?

AOP is about manipulating existing code so it is extended. In the case of compile time weaving (like postsharp does), IL code is manipulated based on what meta data or config file data is provided. At runtime weaving, dynamic proxies are created based on the meta-data provided (attributes or config file). So here, attributes on Types are used to determine if something has to happen to an instance of that given type and if so action is performed, e.g. IL manipulation or a dyn. proxy is created.

Thanks for the info. I've decided to go the property route for my current dilemma because this is one of those cases where a property serves the same function as the attribute. I have an instance and I'm just defining a boolean value about that class.

As for the AOP stuff, I just knew that the .NET AOP people seem to use attributes a lot in their code and was wondering if they used any common libraries to read these attributes...