Attributes or not

[DeveloperX]

Hi, I accidently posted the following to
microsoft.public.dotnet.csharp.general a few days ago when it should of
ended up here, so apologies for the cross post. Any advice is as always
appreciated.
--original message--
Hi,
I've just been reading
http://www.codeproject.com/csharp/data_binding_reflection.asp and I
appreciate what the author is doing, but it raises a couple of
questions.
With the example someone posted in a comment at the bottom, where the
attribute defines whether the property is a currency for example,
surely it would be better to define that information in some external
schema to allow it to be updated with a simple database change or xml
file edit?
The bit of information I'm missing is why would I use a read only
attribute that will require a code change to alter it when I can
achieve the same and make it configurable externally?
I've tried to think of some examples where attributes make sense in
their examples, but each time I come back to externalising that config
info.
Is it just a matter of style? If anyone uses attributes in this manner,

I'd love to hear your experiences.

Thank you
Ian

 

[Marc Gravell]

I kinda agree with Nick Parker's comments; having the data entities
define the UI is (in large projects) a major headache. In 2.0 in
particular this is made so easy anyways with improved BindingSource
support; for grids you can use a DataGridView (IIRC) very easily to
display data-bound properties, and (crucially) it is the UI that
defines both what is shown, and how it is formatted.

Yes, you could do a lot be externalising the UI to configuration and
databinding from there, but this is getting very close to the purpose
of Avalon (WPF) and XAML; personally I'd wait for the new UI engine to
be RTM, and take it from there.

Marc

 

[DeveloperX]

I kinda agree with Nick Parker's comments; having the data entities
define the UI is (in large projects) a major headache. In 2.0 in
particular this is made so easy anyways with improved BindingSource
support; for grids you can use a DataGridView (IIRC) very easily to
display data-bound properties, and (crucially) it is the UI that
defines both what is shown, and how it is formatted.

Yes, you could do a lot be externalising the UI to configuration and
databinding from there, but this is getting very close to the purpose
of Avalon (WPF) and XAML; personally I'd wait for the new UI engine to
be RTM, and take it from there.

Marc

I've had a brief look at XAML before and it's quite interesting stuff.
I also agree with Nick Parker's comments, just not the implementation.
Actually, that's a bit harsh, I could certainly imagine doing as he's
suggested, I like the elegance, but it just seems inflexible. A good
idea wrong approach sort of thing.
My business objects implement some presentation (I call them GUI hints
for some reason) interfaces, so in the same way I leave the actual
presentation to the GUI, but if I want a field to be always hidden, I
can change that without re-compiling, just changing my config data.
I've done some further reading, and I think it's just down to
preference, but if I'm missing some real solid advantage I'd love to
know
I will investigate BindingSource though, thanks for that pointer.
Ian

 

[Marc Gravell]

Sorry for confusion; have re-read, and Nick is the original author,
responding to Marc Scheuner's comments (as an anti-pattern), with Nick
acknowledging the data/UI blurring as a potential issue.

 

[DeveloperX]

Sorry for confusion; have re-read, and Nick is the original author,
responding to Marc Scheuner's comments (as an anti-pattern), with Nick
acknowledging the data/UI blurring as a potential issue.

No problem, I remembered the comments, just made assumptions on the
names

 

[Ignacio Machin \( .NET/ C# MVP \)]

Hi,

I kinda agree with Nick Parker's comments; having the data entities
define the UI is (in large projects) a major headache. In 2.0 in
particular this is made so easy anyways with improved BindingSource
support; for grids you can use a DataGridView (IIRC) very easily to
display data-bound properties, and (crucially) it is the UI that
defines both what is shown, and how it is formatted.

I think that you mean ObjectDataSource , this is the new class that broker
the data binding between data sources and data-bound controls.

 

[Marc Gravell]

No, I meant BindingSource; this is new in 2.0, so I hope it isn't
obsolete already ;-p You can use it as the source property of a
binding.
http://msdn2.microsoft.com/en-us/library/system.windows.forms.bindingsource.aspx

To be honest, I've never knowingly directly used ObjectDataSource, but
I have done plenty of binding, /generally/ with a BindingSource; I will
look at ObjectDataSource, to see if I have been missing anything.
Perhaps this is what BindingSource uses underneath when you bind to a
list of objects...

Marc

 

[Marc Gravell]

Ahh... got it (I think); namespaces says it all...

System.Windows.Forms.BindingSource
System.Web.UI.WebControls.ObjectDataSource

I'm guessing this question relates to WinForms, so I'll stick with my
first answer...

Marc