Чому у вас є мінімальний користувальницький / рукописний код і робити все в XAML?

Я відчуваю, що спільнота MVVM стала надмірною, як програмісти ОО в 90-х - це неправильно MVVM є синонімом коду. З мого закритого питання StackOverflow :

Тут я часто зустрічаю повідомлення про те, що хтось намагається зробити еквівалент у XAML замість коду позаду. Єдиною їх причиною є те, що вони хочуть утримувати код «чисто». Виправте мене, якщо я помиляюся, але це не так:

XAML також компілюється - в BAML - тоді під час виконання потрібно все-таки розбиратися в код. XAML потенційно може мати більше помилок виконання, оскільки компілятор їх не буде вибирати під час компіляції - від неправильних написань - ці помилки також важче відлаштовувати. За цим кодом вже є - подобається він чи ні InitializeComponent (); його потрібно запустити, а файл .gics, в якому він знаходиться, містить купу коду, хоча він може бути прихованим. Це чисто психологічно? Я підозрюю, що це розробники, які походять з веб-фону і люблять розмітку на відміну від коду.

EDIT: Я не пропоную код поза замість XAML - використовуйте обидва - я також вважаю за краще робити своє прив’язування в XAML - я просто проти того, щоб докладати всіх зусиль, щоб не писати код за esp в додатку WPF - це має бути злиттям обидва, щоб отримати максимальну користь від цього.

ОНОВЛЕННЯ: Це навіть не ідея Microsoft, кожен приклад на MSDN показує, як ви можете це зробити в обох.

Я ніколи не чув, щоб хтось пропонував помістити все в XAML.

Насправді це була б жахлива ідея, ІМО.

Проблема, історично, виникла з додатків Winforms, які в коді були логікою, яка там не належала, оскільки це була логіка . Ось звідки і важливість ВМ. Це дозволяє ізолювати деталі, які з'єднують між собою Погляд на модель.

Таким чином, Перегляд залишається лише обробляти те, що найкраще - це інтерфейс користувача.

Тепер, якщо у вас трапляються ситуації, коли ваш інтерфейс вимагає коду, тоді обов'язково відправте його і поставте його у свій код позаду. Однак я б сказав, що для 95% сценаріїв там, швидше за все, вам буде краще залишити користувальницький інтерфейс у файлі розмітки, і якщо вам знадобиться якийсь код позаду, це, мабуть, певна логіка, яку ви намагаєтеся виписати це більш доцільно залишити для перегляду моделі. Винятком є ​​такі речі, як поведінка, але цілком окремі тварини і потребують спеціального місця (тобто не в коді позаду).

Щоб безпосередньо відповісти на ваше запитання і припускати, що коли ви говорите «код», то в кожному випадку ви посилаєтесь саме на відсталий код (код, який знаходиться в класі візуального управління), причина полягає в тому, що ваш інтерфейс користувача може бути повністю реалізований і маніпулювали в Blend, використовуючи лише одну технологію. Припущення полягає в тому, що ваші UX-дизайнери не є розробниками і не хочуть працювати в коді, і що вони є компонувальниками та експертами XAML на відміну від експертів із кодування. Якщо ви реалізуєте все без коду, ви можете надати таким дизайнерам інструменти, які їм потрібні для роботи повністю на їх мові.

Він забезпечує чіткий поділ між імперативним програмуванням та декларативним дизайном.

Це є рушійною причиною існування "поведінки" у Silverlight та WPF - замість того, щоб занурювати якийсь код у код-позаду, зробити поведінку своїм власним маленьким багаторазовим модулем. Якщо ви це зробите, Blend дає вам перевагу в тому, що ви можете буквально перетягнути її на елемент управління. Тепер, замість того, щоб мати одноразову рухому частину для управління, інакше все-в-XAML, ви абстрагували рухомі частини в хороший контейнер, яким можна керувати за допомогою дизайнерських інструментів.

З мого досвіду, це часто зводиться до спроб використання складної логіки в тригерах XAML, щоб уникнути її поза кодом, коли кращим і простішим підходом було б поставити цю логіку ні в одному - це належить до точки зору -модель.

Однією з найбільших переваг робити все, що можна в xaml, є те, що вона зберігає всю поведінку в одному місці. Кожен раз, коли розробнику доводиться переходити між xaml і кодом, зрозуміти це стає складніше.

Я був у команді WPF, яка не зробила скорочення коду пріоритетним. Не раз було кілька разів, що налагодження було набагато складніше, оскільки якийсь обробник подій маніпулював керуванням, і це було не відразу зрозуміло, оскільки поведінка було розкидано навколо двох файлів.

Однак, я вважаю, що ви праві вважаєте, що інколи вам краще робити компроміс за принципом дизайну. Деякі речі дуже важко зробити в xaml. Я витратив години чи навіть дні, намагаючись змусити себе поведінку працювати в xaml, що я міг би зробити за набагато менший час, використовуючи код-позаду. Я прийшов розглядати код-позаду як крайній захід, але ніколи не сказав би комусь, що вони ніколи не повинні його використовувати. Це просто чергове рішення, яке повинен зрозуміти хороший інженер.

редагувати: З коментарів звучить так, що мій пост інтерпретується як аргументація проти xaml. Мій намір полягав у тому, щоб стверджувати протилежне. Чистий ксамл завжди кращий, тому що він тримає всю поведінку в одному місці. Суміш xaml та code-відстань може стати викривленим, тому мінімізація коду-відставання є ідеальною. Xaml є переважним перед чистим кодовим відставанням з багатьох причин. WPF і Silverlight розроблені так, щоб писати у xaml.

У мене є лише дуже поверхневі знання XAML, але це бентежить мене, що компілятор не виявить помилки.

Основна відмінність полягає в тому, що XAML є декларативним , тоді як C # наприклад є обов'язковим.

Простіше кажучи:

Pane p = new Pane(200, 100);
Button foo = new Button("foo");
Button bar = new Button("bar");
p.addChild(foo);
p.addChild(bar);

vs.

<Pane width="200" height="100">
    <Button label="foo"/>
    <Button label="bar"/>
<Pane>

Верхній код дійсно створює ієрархію побічними ефектами, тоді як нижній просто оголошує його. Варто також зазначити, що, наприклад, наприклад, addChildметод може бути перейменований, відносини дитина-батько лежать в основі семантичної моделі і як декларативний фрагмент представлений саме таким. Це дуже далеко від впровадження, що дозволяє значно оптимізувати оптимізацію, наприклад, ледачу інстанцію, повністю прозоро.
Декларативне програмування має ряд переваг. Він більш лаконічний, виразний і дуже близький до вашої моделі. Я б пішов, наскільки це краще.

Однак це не означає, що вам слід спробувати пробити все в XAML. C # має багато конструкцій високого рівня, які дозволяють декларативний стиль.

Зрештою, ви хочете, щоб ваш код був коротким і легким для читання. Отже, якщо ви можете досягти того ж в C # з меншим кодом, ніж у XAML, використання C # є логічним. Майте на увазі, що, однак, код XAML є більш "портативним" в тому сенсі, що він набагато менш вразливий до змін використовуваних компонентів, віддаляючи рамки .NET (наприклад, детальну інформацію про те, як реалізуються прив'язки).