Fun with C#: How to get rid of INPC using Dynamic – Part 4

With what we wrote up to the previous post, we should be able to write the following code:

var viewModel = new InvoiceItemViewModel { ProductName = “Some value" };

dynamic decorator = new DynamicDtoDecorator(viewModel);

The next step is to enable access to the properties through the decorator, like so:

decorator.ProductName = “Some new value”;
Console.WriteLine(decorator.ProductName);

Since the decorator variable above has been declared as dynamic, the compiler won’t complain about the DynamicDtoDecorator not having such a thing as a ProductName property. However, during runtime, the code will blow up when it tries to access that property. Here’s what we need to do to the DynamicDtoDecorator class so it knows how to set a value to a dynamic property:

public override bool TrySetMember(SetMemberBinder binder, object value)
{
    SetProperty(binder.Name, value);
    return true;
}

public virtual void SetProperty(string propertyName, dynamic value)
{
    if (!_members.ContainsKey(propertyName))
        throw new InvalidOperationException({0}#x22;Unregistered member: {propertyName}");
    if (_members[propertyName].Get() == value) return;
    
    _members[propertyName].Set(value);
    RaisePropertyChanged(propertyName);
}

Our DynamicDtoDecorator class inherits from DynamicObject, which provides a TrySetMember method: this method gets called during runtime whenever we try to set a member on the object. Its SetMemberBinder parameter has a Name property, which gives us the name of the member we’re trying to set (in earlier example, that’d be the “ProductName” property). The method also takes in the value we’re trying to set the member to. Finally, the method is supposed to return true or false in order to indicate whether it could successfully set the value or not.

I’ve created a SetProperty method, which is called by the TrySetMember method, just to keep things more organized. This method performs a some simple validation (making sure the given property name is registered within the decorator), sets the value on the property using our PropertyAccessor, and calls RaisePropertyChanged.

The code that allows us to get the value of a property is very similar:

public override bool TryGetMember(GetMemberBinder binder, out object result)
{
    if (_members.ContainsKey(binder.Name))
    {
        var propertyValue = _members[binder.Name];
        result = propertyValue.Get();
        return true;
    }
    result = null;
    return false;
}

So, whenever we try to get the value of a dynamic property, a TryGetMember method is called. It takes in a GetMemberBinder, which gives us the name of the member we’re trying to access, and it also takes in an out parameter to which we set what value we want returned out of that operation. The method itself needs to return a boolean indicating whether or not the method succeeded.

That’s it! The most basic implementation of our decorator is ready: we can instantiate it passing in a ViewModel or other type of DTO, set it to the DataContext in WPF visual elements, and use DataBinding. The data displays on the UI, and should values in properties change, the UI should be updated to reflect the change.

So far, what we’re calling a decorator is really a proxy, since it doesn’t really add much functionality to the underlying object. However, once I got to this point, I started seeing other things I could use this approach for, and the class really became a decorator. But more on that on some other upcoming posts. We’re not done with this series yet!

Leave a comment

Fun with C#: How to get rid of INPC using Dynamic – Part 3

On this part of this series, we start looking at the DynamicDtoDecorator class. We begin by seeing how it takes in the object that it decorates and how it figures out what the public instance properties in the decorated object are, and how to access them. We’ll be seeing how we use the PropertyAccessor class created in the previous installment of this series.

Our DynamicDtoDecorator! We start like this:

public class DynamicDtoDecorator : DynamicObject, INotifyPropertyChanged
{
    public event PropertyChangedEventHandler PropertyChanged = (sender, args) => { };

	void RaisePropertyChanged(string propertyName)
    {
        PropertyChanged(this, new PropertyChangedEventArgs(propertyName));
    }
}

The class inherits from DynamicObject so we can get some dynamic support for free. It also implements INotifyPropertyChanged. “But aren’t we trying to get rid of INotifyPropertyChanged?”. Yes, we’re trying to get rid of it in our ViewModels, but we still need it somewhere for WPF binding to work.

Next, we have a private field to store the DTO (Data Transfer Object) that the class decorates. The DTO is passed into the class constructor

readonly object _dto;

public DynamicDtoDecorator(object dto)
{
    _dto = dto;
    RegisterProperties();
}

Notice that the constructor calls out to a RegisterProperties method. Let’s see what that method looks like:

protected void RegisterProperties()
{
    _dto.GetType()
        .GetProperties(BindingFlags.Public | BindingFlags.Instance)
        .ToList()
        .ForEach(prop =>
        {
            object[] notIndexedProperty = null;
            Func valueGetter = () => prop.GetValue(dto, notIndexedProperty);
            Action valueSetter = newValue => prop.SetValue(dto, newValue, notIndexedProperty);
            Register(prop.Name, valueGetter, valueSetter);
        });
}

The method looks for any public instance property on the DTO type, creates getter and setter delegates, and register them with in the decorator. If you’ve been following my series on this topic, you’ll remember my explanation on a PropertyAccessor class I created in the previous installment, so you can already think how those getter/setter delegates are going to be used, right? Well, alright, I forget things all the time, too, so let’s see what that Register method looks like:

public void Register(string propertyName, Func valueGetter, Action valueSetter)
{
    var fullPropertyName = propertyName;

    if (_members.ContainsKey(fullPropertyName))
       return;

    dynamic initialValue = valueGetter.Invoke();
    var propertyValue = new PropertyAccessor(propertyName, valueGetter, valueSetter, initialValue);
    _members.Add(fullPropertyName, propertyValue);
}

Nothing special going on there. The _members field is defined in the class like this:

readonly Dictionary<string, PropertyAccessor> _members = new Dictionary<string, PropertyAccessor>();

Just a pretty Dictionary, that’s all.

Right now, our decorator knows what it needs to access on the decorated object, and how to access it. In the next part we explorer how this is going to be exposed to the outside world. Stay tuned!

Leave a comment

Fun with C#: How to get rid of INPC using Dynamic – Part 2

el;In Part 1, I mentioned I wanted to decorate a ViewModel with “notify property changed” behavior, so I could keep my ViewModel as clean as possible. In this part I’ll go over how the properties on the decorated object are going to be accessed.

Say we have the following code:

dynamic viewModel = new DtoDecorator(new InvoiceItemViewModel());
viewModel.ProductName = “My great product”;
Console.WriteLine(viewModel.ProductName);

A “non-dynamic” implementation of the decorator could look somewhat like this (disregard the implementation of INotifyPropertyChanged for now):

public class DtoDecorator
{
    InvoiceItemViewModel _decoratedViewModel;

    public DtoDecorator(InvoiceItemViewModel viewModel)
    {
	_decoratedViewModel = viewModel;
    }

    public string ProductName 
    {
        get 
        {
            return _decoratedViewModel.ProductName;
        }
        set
		{
			_decoratedViewModel.ProductName = value;
		}
    }
}

The important aspect in the code above is that the decorator has to be able to access properties on the decorated object. In order to come up with a generic way to do that, I’ve created a PropertyAccessor class, designed to get/set value on a property.

The PropertyAccessor class uses a Func delegate to do the “get” and an Action delegate to do the “set”, like so:

var viewModel = new InvoiceItemViewModel { ProductName = “Some value" };

var getter = new Func(() => viewModel.ProductName);
var setter = new Action(value => viewModel.ProductName = value.ToString());
_propertyAccessor = new PropertyAccessor("ProductName", getter, setter, initialValue);

With that in place, we can get or set that property like so:

_propertyAccessor.Set(“New value”);
var currentValue = _propertyAccessor.Get();

This is what the PropertyAccessor class looks like:

public class PropertyAccessor
{
    readonly Func _getter;
    readonly Action _setter;

    public PropertyAccessor(string propertyName, 
        Func getter, 
        Action setter,
        dynamic initialValue)
    {
        PropertyName = propertyName;
        _getter = getter;
        _setter = setter;
        InitialValue = initialValue;
        CurrentValue = initialValue;
    }

    public string PropertyName { get; }
    public dynamic InitialValue { get; }
    public dynamic CurrentValue { get; private set; }

    public bool Changed => InitialValue != CurrentValue;

    public dynamic Get()
    {
        return _getter.Invoke();
    }

    public void Set(dynamic value)
    {
        _setter.Invoke(value);
        CurrentValue = value;
    }
}

Notice we also keep track of initial and current values so we can do some basic change tracking, which comes in handy.

Now that we have a generic way to get/set value on properties of an object, the next step will be to look at that decorator class. Coming up next!

Leave a comment

Fun with C#: How to get rid of INPC using Dynamic – Part 1

Continuing on with our series on using the dynamic features of C#, let me share how I’ve used it to address an issue that bugged me several years ago.

When creating ViewModels for WPF applications, I got fed up with having to implement INotifyPropertyChanged and pollute the classes like this:

public class InvoiceItemViewModel : INotifyPropertyChanged
{
public event PropertyChangedEventHandler PropertyChanged;

protected virtual void OnPropertyChanged(string propertyName)
{
PropertyChanged.Invoke(this, new PropertyChangedEventArgs(propertyName));
}

private string _productName;

public string ProductName
{
get { return _productName; }
set
{
if (_productName != value)
{
_productName = value;
OnPropertyChanged("ProductName");
}
}
}
}

I didn’t want to see 12 lines in the code for each property exposed. Instead, I wanted to have something like this:

    public class InvoiceItemViewModel
{
public string ProductName { get; set; }
public string Category { get; set; }
public decimal Price { get; set; }
public int Quantity { get; set; }
public decimal Total => Price * Quantity;
}

That’s as simple as the class can get. That’s how I wanted my ViewModels to look like. Notice it doesn’t even inherit from any baseclass, and it doesn’t have any attributes decorating the class (the way I also did at some point when using IL weaving tools such as PostSharp).

WPF databinding is late-bound, so as long as the property exists on the object during runtime, everything works just fine. When it comes to changing data in the UI and having WPF broadcast the message that the some properties have changed, well, the ViewModel needs to raise the PropertyChanged event. So, I decided to go ahead and create a DynamicDecorator class, which would decorate my ViewModels with the “notify property changed” behavior.

Before assigning my ViewModel to the UI’s DataContext property, I’d use the decorator, somewhat like this:

DataContext = new DynamicDecorator(new InvoiceItemViewModel());

In reality, I had an interceptor in my repository that’d do the decoration part automatically for me, but that’s beyond the point here.

In other words, say I had the following code somewhere in my WPF app:

var item = GetItem();
item.ProductName = “Banana”;

The implementation of GetItem could look like this:

InvoiceItemViewModel GetItem()
{
    return new InvoiceItemViewModel();   
}

But then again, since WPF’s databinding is late-bound, GetItem, in my case, looked something like this:

dynamic GetItem()
{
    return new DynamicDtoDecorator(new InvoiceItemViewModel());
}

The DynamicDtoDecorator simply intercepts access to the properties on the ViewModel it decorates, and it raises PropertyChanged when appropriate. I’ll show and explain the implementation of that class on my next post.

Wondering why the class is named Decorator, instead of Proxy? That’s also coming up in another post. Stay tuned!

Leave a comment

Fun with C#: After dynamic features arrived

Today I’ll continue with our series on dynamic stuff, taking it from where we left off in our previous post. So, building on top of the same simple examples, let’s see what changed for me once the dynamic features arrived to C#.

Bending strong typing

Remember how C# is strongly-typed?

var myVariable = 1234;
myVariable = “Woohoo!!”;   // Nope...

We can bend that rule if we declare types as dynamic:

dynamic myVariable = 1234;
myVariable = “Oh, boy…”;

Yes, I hope you can see how writing code like that can cause all sorts of trouble. But, it does come in handy when we have good use for it. Anyway, when we declare something as dynamic, we’re telling the C# compiler “look, the actual type of this will have to be determined during runtime”. Of course, in the sample above, we have an integer and string, so it wouldn’t make sense at all to use dynamic there. However, in real world apps, the actual value types would only be known during runtime.

Now, take this example:

var names = new[] { "Claudio", “Paul" };
var result = names.Select(n => new { Length = n.Length }).ToList();
Console.WriteLine(result.GetType().Name); // List’1 

Notice that the type of result is List’1, because we’re projecting the items into new anonymous types, and using var to let the compiler infer the type.

So what happens if we changed the code to this:

dynamic result = names.Select(n => new { Length = n.Length }).ToList();
Console.WriteLine(result.GetType().Name);  // List’1

By changing the type of the variable to dynamic we told C# the type would only be known during runtime. Regardless, in that case, the type still ends up being List’1 at runtime.

What if we follow that code with this:

result = “Woohoo";
Console.WriteLine(result.GetType().Name);  // string

The type of result would be changed to string, which proves the data type is indeed dynamic.

The ever expanding object

As part of the dynamic features, we also got an ExpandoObject class. If we instantiate that class and type the variable to either ExpandoObject or var, we get access to the members of that class that were statically typed. But the real fun comes in when we type the variable to dynamic. Check this out:

dynamic user = new ExpandoObject();            

user.FirstName = "Claudio”;            
user.LastName = "Lassala”;            

user.FullName = new Func(() => $"{user.FirstName} {user.LastName}");            

Console.WriteLine(user.FullName()); 

In the example above, the FirstName and LastName are properties we added dynamically to that user object. FullName is a method that returns a string.

We could also have defined the FullName method before defining the other properties:

dynamic user = new ExpandoObject();         

user.FullName = new Func(() => {0}#x22;{user.FirstName} {user.LastName}");

user.FirstName = "Claudio”;            
user.LastName = "Lassala”;             

Console.WriteLine(user.FullName()); 

That would still work just fine, given that during runtime, when FullName() was called for the first time, the properties it depends on would already have been added to the object. What if the properties weren’t there already? It’d throw an exception, which we can handle gracefully.

Let’s revisit a sample from previous posts and make it use dynamic:

var instanceType = Type.GetType("Playground.User");            
dynamic instance = Activator.CreateInstance(instanceType);            
object hello = instance.SayHello();            
Console.WriteLine(hello.ToString());

The main change there is that we assign the return of CreateInstance to a dynamic variable. From there on, we can call methods on it that the compiler doesn’t know about during compile time. NOTE: this feature was great when working with Excel automation!!!

Now that we know all of that, going back to the idea that I wanted to instantiate classes and call methods for which I have strings that represent their names (these strings are likely coming from a database or configuration file, for instance). So I’d like to be able to write something like this:

dynamic instance = MakeObject("Playground.User");            
dynamic result = instance.Call("SayHello");            
Console.WriteLine(result);

That’s an easy thing to pull off now that we know about ExpandoObject and dynamic types. Here’s the implementation of MakeObject:

private static dynamic MakeObject(string className)
{    
    var instanceType = Type.GetType(className);    
    dynamic instance = Activator.CreateInstance(instanceType);    

    dynamic expando = new ExpandoObject();    

    expando.Call = new Func((methodName) =>    
    {        
        IEnumerable methods = instance.GetType().GetMethods();        
        var method = methods.SingleOrDefault(x => x.Name == methodName);        
        return method.Invoke(instance, null);    
    });                
    return expando;
}

So we use Reflection to instantiate the given type, add a Call method to an ExpandoObject, which in turn calls the method we want on the real object, also using Reflection, and things just work!

Using Reflection in this case is just one option. If this approach presents a performance issue, the Reflection part can be replaced with other alternatives (IL emit, dynamic compilation of code, building Expression Trees), but the client code of this functionality wouldn’t have to change: it’d still be using strings to know the name of the class to instantiate and the name of the method to call on the object.

This series will continue, as there’s quite a number of some other useful things we can do with this knowledge acquired so far!

2 Comments

Fun with C#: Before there were dynamic features

In my previous post, I mentioned about Visual FoxPro being a weakly-typed, dynamic, object-oriented language, which also featured it’s own SQL (Structured Query Language), and a fast local database. When I got to C#, I found a language that was strongly-typed, object-oriented, with no easy way to perform queries, and very hard to create dynamic behavior. But let me brake that down, pretty much the way I did with FoxPro in the previous post:

Object-Oriented

Instantiate an object and call a method on it. Similar to the way I did in FoxPro, but with a key difference: the class name isn’t a string passed into a function!

User user = new User();
user.SayHello();

SQL (Structured Query Language)?

In the first two versions of C# there was just no easy way to query things. But then we were presented with LINQ (Language Integrated Query) in version 3!!

myCustomers = from c in customers 
                           where c.Id == 1 
                           select c;

customer = myCustomers.SingleOrDefault();

customer.Address 
customer.PhoneNumber 

That was very similar to the way I could do a SELECT followed by a SCATTER in FoxPro. I loved it!

I didn’t like the way the code read, though, with the “select” coming at the end (after so many years of starting my queries with SELECT). Once I got over that, I started to appreciate the fact that I could write my queries like this:

customer = customers.where(c => c.Id == 1).SingleOrDefault();

Or even better, like this:

Customer customer = customers.SingleOrDefault(c => c.Id == 1);

“What does that have to do with the topic of this series?”, you might ask. Stay with me…

Strongly-typed

Consider the following code:

var myVariable = 1234;
myVariable = “Woohoo!!”;   // Nope...

Well, since C# is strongly-typed, knowing the type of data we get back from queries is very important. Take this example:

var customers = customers 
                 .SingleOrDefault(c => c.Id == 1)
                 .Select(c => new { Address = c.Address, PhoneNumber = c.PhoneNumber  });

When C# 3 introduced type inference, many developers were confused with the keyword var, thinking it meant “variant”; in other words, a variable declared as var should be assigned different types of data at will. That was not the case; var was just a way to tell the compiler “hey, the type of this variable will be whatever type I’m assigning to it as I declare it.”

With that said, in prior examples we were having the query return a Customer object. In the example above, on the other hand, we return some sort of list of anonynous objects, by using the new keyword without the name of a class, but giving it the properties and initial values we want on them. So we just told the compiler “I need a new object that has these properties with these values”. The compiler creates a class for us containing those properties; it is not a class created dynamically during runtime.

Now, let’s take that example a step further:

var customers = customers 
                  .SingleOrDefault(c => c.Id == 1)
                  .Select(c => new { c.Address, c.PhoneNumber  });

customers = “can’t do this!”;

Again, we declare a customers variable, and let the compiler infer its type. Next, we try to assign some string content to that same variable. The compiler yells at us, proving that var does not mean variant.

Dynamic (before C# Dynamic)

Let’s now have a look at how we implement dynamic things before the so-called “C# Dynamics” were introduced. Let’s revisit this simple sample:

User user = new User();
string hello = user.SayHello();
Console.WriteLine(hello);

What if we didn’t know during compile time what type of User to instantiate? And what if we only knew during runtime what method to execute? The way to that back then was only by using .NET Reflection, like so:

var instanceType = Type.GetType("Playground.User");            
object instance = Activator.CreateInstance(instanceType);            

MethodInfo theMethod = instanceType.GetMethods().SingleOrDefault(m => m.Name == "SayHello");           
object hello = theMethod.Invoke(instance, null); 
           
Console.WriteLine(hello.ToString());

That way, both the class and method names where represent by strings. When doing that, we always work with object; that’s what the Activator’s CreateInstance method returns, and it’s also what the Invoke method on a MethodInfo instance returns. Using type inference here (declaring the variables with var) wouldn’t help us much.

Another option to create some sort of dynamic code back then was by emitting IL (Intermediate Language). Not exactly a fun thing to do. There are good cases for it, though, so check out some real world users of Reflection.Emit.

Yet another option, which I’ve used at least twice in successful projects, was to build C# code as strings within the application, and handle it over to the C# compiler during runtime. What type of code got created dynamically was controlled within the application, and it was executed within a sandbox, so the end-users couldn’t really “do anything they wanted”. In fact, I have used this approach in conjunction with the dynamic features once they become available.

Coming up next, dynamic code after the C# dynamic features arrived. Stay tuned!

Leave a comment

Fun with C#: Dynamic Features – Why did I care?

I was glad to see dynamic features available in C# back when version 4 came out (in 2010, if memory serves me right…). But, why did I care?

Back in my old days, prior to start working with .NET, I was working heavily on Visual FoxPro projects. FoxPro was a weakly-typed, dynamic, object-oriented language, which also featured it’s own SQL (Structured Query Language), and a fast local database. Now, what does all mean?

Object-Oriented

I could define a class (say, “User”), instantiate it, and call methods on it (such as, “SayHello”):

SQL (Structured Query Language)

FoxPro allowed me write code like this:

SELECT Address, PhoneNumber FROM C:\DB\CUSTOMERS.DBF 
    WHRE Id = 1 
    INTO C:\TEMP\TEMP_CUSTOMERS.DBF 

No need to create a connection to a database: I could simply query some data off of a local file, and even dump into to another local file.

I could also create an object out of the current row off my query results, with properties matching the columns in the table (think Entity Framework reading data off a database and pushing into objects for you):

SCATTER NAME customer 
customer.Address 
customer.PhoneNumber 

 

Weakly-typed

We could assign an integer to a variable in one line, and then assign a string to it in another, and FoxPro was happy:

myVariable = 1234 
myVariable = “Woohoo!!”

Nope, that wasn’t necessarily a good thing, as people definitely abused that possibility. However, there were scenarios where it came in handy.

Dynamic

I could do the following:

1. Put the name of a class to instantiate and the name of a method to call in a string (both could be coming from a database):

className = “User”
methodName = “SayHello"

2. Merge those variables to another string variable representing lines of code:

text to someVariable texmerge noshow 
        instance = CreateObject(“<< className >>”)
        result = loInstance.<< methodName >>()
        MessageBox(result)
endtext 

3. Execute the code contained in that string variable like so:

&someVariable 

 

Putting it all together

So it was common to see code somewhat like this:

SELECT ClassName, MethodName 
    FROM WhateverTable 
    WHERE Module == “Hello World”

SCATTER NAME behavior 

text to someVariable texmerge noshow 
        instance = CreateObject(“<< behavior.className >>”)
        result = loInstance.<< behavior.methodName >>()
        MessageBox(result)
    
        result = 1234 
        MessageBox(result)
endtext 

&someVariable 

In reality, some FoxPro projects store entire modules created based off dynamic code like the one above, stored in databases.

Rewriting FoxPro “dynamic” software in .NET

I’ve worked in projects where the client wanted those FoxPro “dynamic” applications rewritten in .NET. I’ve been told many times that “our application is 100% dynamic; everything can be configured by the end-user”. I’ve even blogged about that. In the end, not everything was dynamic, but there were dynamic parts, indeed:

Users could:

  • Extend the system by adding new tables (but always based off existing ones);
  • Add columns to existing tables
  • Define what columns show on the grid
  • Define how columns, rows, and cells where displayed (background color, enable/disable, header, etc.)
  • Create CRUD screens for those columns they added;
  • Create reports using those new columns;
  • Create “expressions” that are evaluated in several situations (enabling/disabling a field, setting the default value of a field based off other fields, etc.). For example, maybe the default value for a new “Total” column in a table should be the result of the following expression (imagine that both Price and Quantity are also columns added by the user):
    • context.Product.Price * context.Item.Quantity
  • Etc.

Reproducing some of those pieces in C# wasn’t exactly easy back then, so this posts answers why I cared about the dynamic features introduced in C# several years ago.

In the next post I’ll go over what I did before the dynamic features of C# came around.

Leave a comment