Is it unconventional to use a Property this way?

Question

I am creating a custom button control for a WPF application. The Button contains a ViewBox which in turn contains a TextBlock like this;

<Button>        
    <Viewbox>
        <TextBlock Name="TextHolder"/>
    </Viewbox>
</Button>

I want outside classes in C# to be able to access and change the text directly via a Property, like so;

public string Text
{
    get { return TextHolder.Text; }
    set
    {
        TextHolder.Text = value;
    }
}

I am wondering if this is consider bad practice or not?

Thanks.

You may be better off posting this question at https://codereview.stackexchange.com/ to get some good feedback there. — idream1nC0de, Mar 30 '18 at 18:38
If `Text` is a property in your custom WPF control, it is probably better to make it a DependencyProperty. (https://stackoverflow.com/a/18592862/2819245) — , Mar 30 '18 at 18:38
Why limit it to text and not allow a full `ContentControl` like WPF's default button class? — Ron Beyer, Mar 30 '18 at 18:41

score 0 · Accepted Answer · answered Mar 30 '18 at 18:57

This piece of code of yours allows the part of the code that is responsible for "business logic" to look like:

this.Text = "mom";

instead of for example:

this.TextHolder.Text = "mom";

Difference is in accessing/exposing the TextHolder UI component. You don't want to expose them. That should be just a details of the 'presentation style'. Ideally the code should not care how the visuals look like (well, unless you are actually writing the code for the visual component like 'TextBlock'). What if you change your UI and TextHolder is no longer there and now you have a different presentation of the text, and it for example doesn't have control.Text but rather control.Data or control.Content? If TextHolder were exposed, you'd have to correct the code everywhere. With your piece of code, that "everywhere" uses your property this.Text, and TextHolder is hidden, so when it's gone, you just change the Text property getter/setter. This is a great thing.

And that's why, if anyone told you anything negative about this, would be wrong. Everything is better than scatterring accesses to UI component all over your business logic code. If you wanted to address that problem and came up with such a solution - great!

That being said, it's not the best you could have, and this is where the praise ends.

First of all you said you are using WPF. In WPF you there's a mechanism called data bindings. If you never used it, let me just say it's .. powerful. Unwieldy at times, but powerful. If you learned to and used data bindings, you would still have the Text property, but your code would not have TextHolder at all, not even in the getter/setter of .Text

Going further, once you learn at least the basics of data bindings, you can take it further and look at MVVM pattern. This one has the power of annihilating .xaml.cs and moving everything to view-agnostic "view models" - plain C# classes that have Properties and that never touch UI directly. WPF has mechanisms to observe them for any changes in their properties and then automatically refreshing the UI. It works two way - clicking/writing to a control may refresh properties in the "view model".

But there's a cost. It's all fine and dandy, but requires you to write some a bit repetitive boilerplace code and keep some defined patterns (though tools like i.e. PostSharp can do it for you, or frameworks like Caliburn.Micro can greatly simplify data binding expressions in XAML..).

Thank you so much for your help! MVVM is the way forward I think, it's how I program already without formalising it. I have been out of programming for a couple of years and am seeking to get back in, so I shall follow some of those lines of learning! Thanks again! — Tristan Trainer, Mar 30 '18 at 20:43

Is it unconventional to use a Property this way?

1 Answers1