Как Вы не допускаете логику представления в модель и бизнес-логику из модели представления в MVVM?

Здесь необходимо рассмотреть две проблемы: удобочитаемость и понятность

Решение «читабельность» - это вопрос стиля, и поэтому оно открыто для интерпретации. Я предпочитаю это:

if (var1 == true && // Explanation of the check
    var2 == true && // Explanation of the check
    var3 == true && // Explanation of the check
    var4 == true && // Explanation of the check
    var5 == true && // Explanation of the check
    var6 == true)   // Explanation of the check
    { }

или это:

if (var1 && // Explanation of the check
    var2 && // Explanation of the check
    var3 && // Explanation of the check
    var4 && // Explanation of the check
    var5 && // Explanation of the check
    var6)   // Explanation of the check
    { }

Тем не менее, этот вид сложной проверки может быть довольно сложно проанализировать мысленно при сканировании кода (особенно если вы не оригинальный автор). Подумайте о создании вспомогательного метода, чтобы абстрагироваться от некоторой сложности:

/// <Summary>
/// Tests whether all the conditions are appropriately met
/// </Summary>
private bool AreAllConditionsMet (
    bool var1,
    bool var2,
    bool var3,
    bool var4,
    bool var5,
    bool var6)
{
    return (
        var1 && // Explanation of the check
        var2 && // Explanation of the check
        var3 && // Explanation of the check
        var4 && // Explanation of the check
        var5 && // Explanation of the check
        var6);  // Explanation of the check
}

private void SomeMethod()
{
    // Do some stuff (including declare the required variables)
    if (AreAllConditionsMet (var1, var2, var3, var4, var5, var6))
    {
        // Do something
    }
}

Теперь при визуальном сканировании метода SomeMethod реальная сложность тестовой логики скрыта, но для людей сохраняется семантическое значение понять на высоком уровне. Если разработчику действительно необходимо понять детали, можно изучить метод AreAllConditionsMet.

Это формально известно как шаблон рефакторинга «Разобрать условно». Такие инструменты, как Resharper или Refactor Pro! может упростить выполнение такого рода рефакторинга!

Во всех случаях ключом к читаемому и понятному коду является использование реалистичных имен переменных. Хотя я понимаю, что это надуманный пример, «var1», «var2» и т. Д. не являются приемлемыми именами переменных. У них должно быть имя, которое отражает основную природу данных, которые они представляют.