Dynamic в C#: рецепты использования

Вариант с Visitor-ом любопытный, но в данном случае использование dynamic-ов добавляет не так уж много преимуществ. У меня как-то был похожий случай, где как раз применение dynamic-ов сильно помогло.

Во внешней библиотеки определены 2 класса, не имеющие общего предка, но имеющие несколько идентичных полей, с которыми должен работать наш метод.
Будь это наши классы, это можно было бы решить добавлением интерфейса с необходимыми полями, но т.к. это внешняя библиотека — не вариант.

Решение:

public class ExternalClassA
{
  // lots of properties
  public string PropertyA {get; }
  public int PropertyB { get; }
  // lots of other properties
}

public class ExternalClassB
{
  // lots of properties
  public string PropertyA {get; }
  public int PropertyB { get; }
  // lots of other properties
}

public class OurClass
{
  public void DoSomeWork(ExternalClassA subject)
  {
     DoSomeWorkInternal((dynamic) subject);
  }

  public void DoSomeWork(ExternalClassB subject)
  {
     DoSomeWorkInternal((dynamic) subject);
  }

  private void DoSomeWorkInternal(dynamic subject)
  {
     // here we can safely operate with subject.PropertyA, subject.PropertyB
  }
}

Т.е. под каждую реализацию, с которой мы планируем работать, создаем публичный метод, приводящий аргумент к dynamic и пробрасывающий вызовы в закрытый метод. Внутри него мы точно знаем, что извне не придет чего-то неподдерживаемого, а от изменений сигнатуры внешних классов страхуемся юнит-тестами.

Раз в тегах стоит dlr то без использования dynamic во ViewModel статья выглядит как черновик.