0

First of all, I am using .NET Framework 3.5 C# 3.0 and Visual Studio 2008.

Having said that... When using MVVM pattern in WPF applications, I am always using view model properties to bind to objects in the view. When calling OnPropertyChanged from the set implementation I always hard-coded the name of the property as a string.

private string _myProperty;
public string MyProperty
{
   get 
   {
      return _myProperty;
   }

   set
   {
      if (_myProperty == value) return;
      _myProperty = value;

      OnPropertyChanged("MyProperty");
   }
}

So I always think if there is any way to avoid property name to be hard-coded.

I know there are methods such as using nameof as explained here and here but this is only available in C# 6.0 (.NET Framework 4.6 and above).

Also exists CallerMemberName attribute as explained here and here but again it was released and is only available in C# 5.0 (.NET Framework 4.5) and later.

So I am using .NET Framework 3.5 C# 3.0 hence that I cannot use this approaches.

So how can I avoid property name to be hard-coded when passing it as a paramenter to the OnPropertyChanged method? I would like a solution that do not compromise performance.

Willy
  • 9,848
  • 22
  • 141
  • 284
  • 1
    May I ask why you have to use such an old Framework? – Klaus Gütter Jan 05 '19 at 13:41
  • 1
    If you are not satisfied with Flat Eric's answer on your question, please check Mark Gravell's answer to this question (note that it is not the accepted answer) https://stackoverflow.com/questions/491429/how-to-get-the-propertyinfo-of-a-specific-property Maybe it will point you in the right direction to avoid strings, but I'm not sure if it will satisfy your performance demand, as it uses reflection and lambdas. – K. Kirilov Jan 05 '19 at 15:36
  • @KlausGütter It is simple: Because the company in which I am currently, they are out-dated and they have not updated/migrated their apps to new Framework for years, so now all the applications are build with this old Framework and they need to be maintained. They are medium-big and complex apps, not easy to migrate quickly, a lot of time is necessary for analyze and migrate them. And maybe your are thinking.... "so why not migrate apps to new .NET Framework? What are you waiting for?" – Willy Jan 05 '19 at 15:52
  • @KlausGütter Because there are many factors here that must be taken into account: we are a very very small team, and each of us have to do a lot of work each day, we are very overworked, so we have no time to invest in migrating. Also the boss thinks in a way that is not correct: "Apps are working so why migrate?" And this is not correct, Many times I have told him and the rest of the team that we have to migrate them NOW but they neither listen nor admit ideas (all are excuses) so It's hard to work with people like this... – Willy Jan 05 '19 at 15:53
  • @KlausGütter Seems like they do not want to evolve and they are leveraged. The other problem is the mentality that the company has: People in charge of hiring do not want to hire more programmers/analysts. The result is: a very very very small team with a lot of apps to maintain in old Framework. We need more programmers but.... this is the reality. There are companies and companies.... there are bosses and bosses.... scenarios and scenarios, and so on.... – Willy Jan 05 '19 at 15:53
  • @K.Kirilov Thanks for the link, it seems interesting. Basically it's the same as the one proposed by Petr. I would like to know what is the speed difference by using hard-coded string against using reflection/lambdas in terms of performance. You know? I have used reflection very little. Is the use of reflection/lambdas introducing a big impact in term of performance (speed, memory, etc.) or is it negligible? – Willy Jan 05 '19 at 18:01

2 Answers2

1

If you are limited by .net 3.5 try this:

Get the property name used in a Lambda Expression in .NET 3.5

assuming there is a class around the property this is an example of use GetPropertyName(this.MyProperty)

it needs using System.Linq.Expressions; using System.Reflection; both seems to be there

Petr
  • 83
  • 7
  • @user1624552 if you are worried about overhead that is actually a valid concern. It is obviously slower than plain string but the notify function is already a drag. You can use performance profiler to see if is a "hot" spot. It is only problem if call it periodically a often. Technically it makes no sense to cal it more often than refresh rate, so if that happens in your code, consider synchronize this property with UI refresh rate and no faster. Keep the actual value only in the "business logic" code. – Petr Jan 05 '19 at 20:44
  • The actual CPU time is about 30%of the notify function so not to bad. My PC can do ~50000 calls per second so it should not be a big deal. :-) – Petr Jan 05 '19 at 20:47
0

You can use nameof operator, independent of the used framework. It is a language feature and not a framework feature

OnPropertyChanged(nameof(MyProperty));

This will work because the compiler converts this expression to a string when converting it to MSIL code.

All you need is Visual Studio 2015 (or 2013 with a nuget package, as far as I know)

Flat Eric
  • 7,971
  • 9
  • 36
  • 45
  • Sorry, As far as I Know, I think you are wrong, nameof is a new feature that was introduced in C# 6 so .NET Framework 4.6 and Visual Studio 2013/2015. Anyway, I am working with Visual Studio 2008... I forgot to say (I have updated the question to indicate it). – Willy Jan 05 '19 at 16:02
  • I tested with a .Net 3.0 project and it worked but it will not work in VS2008. You are right that is was added in C# 6 but not all new features require a new framework version, some only need a new compiler version, i.e. new Visual Studio Version – Flat Eric Jan 05 '19 at 16:05
  • Yes, you are right, sorry. I have checked it. As you say, it is a language feature, not a framework feature, so in this case, it only depends on Visual Studio version (compiler version). – Willy Jan 05 '19 at 16:13