Do you think C# attributes (or similar mechanisms) are a good idea or do you discourage the use of them?

Question

I have based many designs and frameworks that use C# Attributes over the past 4 or 5 years.

But lately I see many people openingly discouraging their use or changing their frameworks to reduce the need or use of them.

I found them to be a godsend but now I am starting to wonder what I am missing.

To clarify: Use Convention over Configuration is becoming a major principle to follow especially in the ORM field. Is this area you can map fields with a config file (XML), use an attribute, or have a common naming convention that maps directly to fields in your database tables. I don't have any references to quote but I have read some backlash against adding another Attribute to the mix.

But I feel over the three choices I just listed that Attributes still make the most sense. A Config file is harder to maintain and a common naming convention ties you to the implementation of the database field. Attributes are placed exactly where they are needed and the implemntation can change without disconnecting from where it is used.

Answer 1

This is a hard question to give a general answer for. Attributes are another language feature that are incredibly powerful when used correctly but do have the potential for abuse. I haven't ever seen a compelling reason to dump the use of attributes altogether and really no reason to think they are a bad idea.

In fact the exact opposite is true. Attributes allow for adding framework specific information into the metadata. Information that simply cannot be easily expressed via a type hierarchy. This dramatically increases the power of frameworks that use attributes.

I've certainly seen an implementation or two where people abused them a bit but nothing spectacular. Can you be more specific? Are there specific attributes / frameworks you're talking about.

Answer 2

I find them extremely useful when it comes to defining meta-data about my code. I use them to generate custom reports, for plug-in architectures, and for communicating to third-party code.

I suppose you can do everything by convention, but I like them.

Answer 3

Well, if ASP.NET MVC is anything to go by, I'd say don't worry about it. So much is done in that Framework using reflection and attributes, that I don't see any issues with it. MVC is a fairly new framework, and it's used all over the place. From validating input, handling errors, to the very awesome ActionFilter attribute, there's alot of them. So no, I personally see nothing wrong with them.

Answer 4

That's a pretty broad question, like "should I put cheese in my casserole"; The answer to both is "it depends on what you're making".

If you're making heavy use of addributes and using them almost like a declarative programming paradigm, then you're probably going to run into trouble along the way. Whether it comes from a slowdown somewhere in reflection or just general maintainability is anybody's guess.

It's like everything else...use them when they're appropriate and make your code more efficient or readable. Don't use them for the sake of using them, and don't abandon them for the sake of abandoning them.

Answer 5

I see heavy use of Attributes in ASP.NET MVC. In fact, switching to MVC has caused me to increase my use of Attributes significantly. I'm not sure where your perception of anti-Attribute backlash is coming from, but I certainly don't see it from MS, at least with respect to MVC.

I particularly like the way that Attributes can be used to provide cross-cutting behavior (aspects) across those controller/actions that are so decorated. Seeing how MVC is built to handle attribute invocation before and after action invocation, I've got to believe that this is the preferred way to get aspects to work in MVC.

Answer 6

There are really two purposes of attributes: as user visible things, and as things emitted by a compiler.

I assume you are talking about user visible attributes.

In general, I would say that user visible attributes are not ideal.

Most of the time they are used to embed some form of custom language on top of C#. DLINQ attributes are a good example of this. A better approach, from the consumer's perspective, would be to add first class support to the host language. That would end up feeling much more natural. (having language support for defining tables and foreign keys would be much easier to work with then all the crazy linq-to-sql attributes).

In reality, however, extending a programing language is too cost prohibitive for most developers. The benefits just don't out weigh the costs.

Perhaps someday C# will have meta-programing features, which will make doing that kind of thing easy.

At the moment, however, that capability does not exist.

This leaves you with 3 options:

1. Use attributes
2. Use a dynamic language, and generate code at runtime
3. Just don't use generative programing

Usually #1 ends up being the easiest choice to make, even if it isn't ideal.

Answer 7

I personally think attributes, like most language features, have their place, but can be abused or misused.

In the correct framework, they are invaluable. They definitely simplify things like DI frameworks (MEF is a great example), and are very, very useful for things like testing frameworks.

I think going crazy adding user defined attributes can be overkill, however. I personally love using attributes, but try to keep their usage to a minimum, and only use them where they make the most sense.