|
Orm Mapping e.g.
[Table("MyFooTable")]
{
[Column("ColumnName", DbType.Varchar, 255)]
public string Bar {get; set}
[Column]
public string Baz {get; set}
}
The above psuedocode pretty much, but I have seen it done like this. There are similar things for serialization. You should try googling for ".net data annotations" - these are really useful for UI work.
|
|
|
|
|
See my real world example:
It's awesome when you figure its power
"To alcohol! The cause of, and solution to, all of life's problems" - Homer Simpson
|
|
|
|
|
Localization tools for WPF applications are crap, so I had to roll my own. I use a custom attribute to mark translatable properties in my custom controls. I may eventually enhance my attribute to support passing useful information to my localization tool for display to the translators.
Software Zen: delete this;
|
|
|
|
|
Interesting. I'm writing a GUI for XNA and don't have any concept for localization yet. You have not written an article about this?
And from the clouds a mighty voice spoke:
"Smile and be happy, for it could come worse!"
And I smiled and was happy
And it came worse.
|
|
|
|
|
Not yet. I'll give it some thought.
Software Zen: delete this;
|
|
|
|
|
Data annotations are a peach, as are the ones to secure the action methods on controllers.
I very rarely hand-roll my own anymore, even those were either for serialization or (once) to create my own ORM framework in lieu of the EF being supported. I'm thinking of creating one so I can secure action methods decorated with it form the database, but for now I'm KISSing it.
|
|
|
|
|
If you are referring to custom attributes, then I have never used any. If you are referring to built-in attributes (.Net or third party controls, dlls) then all the code I have written so far uses them.
"The worst code you'll come across is code you wrote last year.", wizardzz[ ^]
|
|
|
|
|
There are only three reasons I use attributes:
1. XML Serialization
2. Designer info used by the property grid
3. Metadata describing how my plugins intercept SQL transactions
The third isn't necessary and may eventually be replaced with a standard plugin API call to discover the desired behavior rather than using reflection.
I used to think that attributes were the cat's meow. After using them extensively, I discovered that they are just another layer of obfuscation that complicates the maintenance of the code. I realized that a much better implementation would have been to keep the the imperative code separate from the metadata declarative portions. As it stands, the source code combines both. What I think would be better is a separate, purely declarative, repository as a map of the imperative code and the desired attributes. This would have allowed the attributes to vary independently from the code. Consider changing a serialization attribute, like the XML attribute name, or a description of a property to assist the form designer. Good grief, I have to touch the code base to do that? Absurd, in my opinion.
So that's what I've learned over the years, is that the code and the attributes should actually have been kept physically separate.
Marc
|
|
|
|
|
Hmm, the classes used to hold attributes are very simple data containers. They have the advantage that you can declare, change and inherit them as you need them, also including own types if it must be. Also, seen from a framework developer's view, they are never modified. Deprecated and replaced by another perhaps, but not simply changed.
And from the clouds a mighty voice spoke:
"Smile and be happy, for it could come worse!"
And I smiled and was happy
And it came worse.
|
|
|
|
|
Marc Clifton wrote: After using them extensively, I discovered that they are just another layer of
obfuscation that complicates the maintenance of the code
Isn't it always this way with coding "conveniences"? People think their code is better when they use the latest/greatest language/framwork feature, but all it serves to do is to confuse new people working on a given project, and hopelessly slows down orientation of rookie programmers. I don't even use lamdas a lot, and for the very same reason. I only use attributes in very rare instances - when they're required, and for nothing more. On a semi-related note, I try to avoid using reflection whenever possible as well.
".45 ACP - because shooting twice is just silly" - JSOP, 2010
-----
You can never have too much ammo - unless you're swimming, or on fire. - JSOP, 2010
-----
"Why don't you tie a kerosene-soaked rag around your ankles so the ants won't climb up and eat your candy ass." - Dale Earnhardt, 1997
modified 17-Oct-11 12:38pm.
|
|
|
|
|
+5 for keeping it short and simple - only when it adds value (shorter/more readable code/better maintainability/etc.)
Bastard Programmer from Hell 
|
|
|
|
|
It hurts my eyes to see such conservatism in developers. Do you seriously avoid DataAnnotations, WebServices, WCF Contracts, ASP.NET MVC post/get descriptors etc?
Attributes are great for many reasons:
1)They are declarative. They abstract the actual painful order of details, they just do what you tell them to do
2) They are where they should be. Decorating your method, property or whatever, not in some hidden config file you easily forget to update. You don't want them there for some important reason? There are workarounds (see entity framework and Metadata classes which add data annotations).
3) They combine well with OO programming (abstraction, data together with their behaviour etc etc)
4) You can do sexy things with them with reflection
5) Their most common uses are dead-simple to understand (a junior developer who cannot understand in 10 minutes what [Post] or [Required] can do in the appropriate context, just shouldn't be a developer).
6) In most cases they are the most brief way to express something
7) It's one of those features Java was so eager to copy, for a reason.
8) You cannot seriously compare attributes with lambdas in their complexity. (even though I love lambdas as well).
9) Of course they can be abused, but even "if" can be abused (I've seen horrible series of if statements that could have been replaced by a more maintenable and faster to execute switch).
modified 6-Apr-21 21:01pm.
|
|
|
|
|
WCF can be listed solidly under "when it's required".
tecgoblin wrote: 4) You can do sexy things with them with reflection
WTF do I want code to be sexy for? I just want it to work and be maintainable. When I'm writing code, I'm usually not thinking about "sexy". Reflection is handy, but I avoid it whenever possible.
tecgoblin wrote: 7) It's one of those features Java was so eager to copy, for a reason.
Well, there's a valid reason to use attributes - because they wanted to do it in Java... That's like saying goto is a viable statement.
tecgoblin wrote: (even though I love lambdas as well).
Wow. Color me surprised.
".45 ACP - because shooting twice is just silly" - JSOP, 2010
-----
You can never have too much ammo - unless you're swimming, or on fire. - JSOP, 2010
-----
"Why don't you tie a kerosene-soaked rag around your ankles so the ants won't climb up and eat your candy ass." - Dale Earnhardt, 1997
|
|
|
|
|
Like so many things - there is a time and a place. People who use attributes wisely can achieve good outcomes with clean and simple code. The key is to know what REALLY happens behind the scenes when you add attributes. If you don't know this then don't use the attribute. For example, the LINQ object-to-database mapping can be a very useful tool but used incorrectly it generates disasterously slow code behind the scenes.
|
|
|
|
|
Our intern told me that I'm old school and that we don't have to worry about memory or the CPU nowadays. We just have plenty of both 
But he already started to change his mind. He started to write an app on his telephone and 'only' has a 1 GHz ARM processor and 64kk memory. Extremely limited 
And from the clouds a mighty voice spoke:
"Smile and be happy, for it could come worse!"
And I smiled and was happy
And it came worse.
|
|
|
|
|
I don't know who 1-voted your post, but I don't think it was necessary and compensated with a 5.
".45 ACP - because shooting twice is just silly" - JSOP, 2010
-----
You can never have too much ammo - unless you're swimming, or on fire. - JSOP, 2010
-----
"Why don't you tie a kerosene-soaked rag around your ankles so the ants won't climb up and eat your candy ass." - Dale Earnhardt, 1997
|
|
|
|
|
Cheers!
modified 6-Apr-21 21:01pm.
|
|
|
|
|
Amen to that. Attributes are GREAT for cross-cutting concerns. One of the most useful applications of attributes I've seen is in ASP.NET MVC. Simply decorating your controller methods with an [Authorize] attribute ensures security for the view. It makes it nice and easy to see which controller methods are secure and which ones are not by simply glancing at the code. Much nicer and more maintainable than an inheritance/opt-in/opt-out OO mess.
Like anything, attributes can be abused, but they definitely have utility in creating readable/maintainable code in cross-cutting circumstances.
|
|
|
|
|
I agree with you completely, got my 5. I posted an example where custome attributes can be very useful:
It's awesome when you figure its power
"To alcohol! The cause of, and solution to, all of life's problems" - Homer Simpson
|
|
|
|
|
John Simmons / outlaw programmer wrote: I only use attributes in very rare instances - when they're required, and for nothing more.
How about when they make your life easier? You'd be surprised on how well they can do that. The fact the something isn't needed doesn't mean you shouldn't use. If one would follow that line, we don't need visual studio, but do we want to code in a text editor and command line?
John Simmons / outlaw programmer wrote: I try to avoid using reflection whenever possible as well.
This may be a valid point not to use Attributes, but then, you gotta verify the advantages and disadvantages of using them. Two disadvantages:
1 - Performance. But is performance a real issue? I believe in most cases they aren't specially on the web where the bottleneck is somewhere else.
2 - Type safety. Ok, but IMO, the productivity gain in most cases outweighs the risks.
"To alcohol! The cause of, and solution to, all of life's problems" - Homer Simpson
|
|
|
|
|
Indeed, the way the propertygrid uses them greatly limits its extensibility.
I think Resharper uses both in the code (defaults) and out of the code (custom settings) attributes for its static analysis engine. Maybe what you describe is somehow exposed in .NET?
|
|
|
|
|
Stonkie wrote: Indeed, the way the propertygrid uses them greatly limits its extensibility.
There's a couple snazzy articles here on CP regarding extending the property grid. I first took control of the property grid in conjunction with a custom form designer so that I could restrict the properties that were exposed. Then I realized, I could do the opposite--expose domain-specific properties that I don't want polluting the agnostic framework. The implementation I decided on uses an external file that associates new properties based on type, and an interface that must be supported for extensible types as a compromise to making my life easier with serialization. So, what I've got now is pretty cool.
Marc
|
|
|
|
|
I beg to differ, please read my post:
"It's awesome when you figure its power"
"To alcohol! The cause of, and solution to, all of life's problems" - Homer Simpson
|
|
|
|
|
Agreed, and attributes may not even be needed for XML serialisation.
|
|
|
|
|
With the amount of participants this poll can give some nice pointers on what and how technology is used.
Now, what decisive role do Attributes have to deserve this poll?
At the end of this week, what can we take from whatever result this may end up with?
I can foresee a "None!" response here 
Sorry guys, I like to contribute but this one felt too useless.
|
|
|
|
General 
News 
Suggestion 
Question 
Bug 
Answer 
Joke 
Praise 
Rant 
Admin 
Submit an article or tip
