Является ли привязка данных плохой идеей?

Как мы говорим в UK, "It's Horses for courses"

Во-первых, я согласен с вами! Но...

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

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

Иногда вам просто нужно "get it done and done quick". Для внутренних приложений, систем бэк-офиса и приложений технического обслуживания, которые редко используются или очень динамичны (часто меняются спецификации), тогда нет никакого оправдания в создании решения Rolls Royce для этого. Лучше заставить разработчика тратить время на CRITICAL часть системы.

То, что вы должны избегать / предотвращать, - это использование этих решений "one click framework" в критически важных областях системы, где важна большая скорость транзакций и качество и целостность данных. Потратьте качественное время на бритье миллисекунд на наиболее часто используемой области в системе!!

Еще одна дискуссия (у нас их было много в эти дни!) в нашей работе является ли привязка данных плохой идеей или нет.

Лично я считаю, что это очень плохо.

Сильное мнение, но имхо, вы приводите все неправильные причины.

1. Это обходит мой хорошо архитектурный фреймворк MVP - с привязкой данных представление взаимодействует с моделью двунаправленно. Тьфу.

   Я думаю, что это зависит от реализации привязки данных. В первые годы моей карьеры программиста я использовал множество VBA для программирования MS Access, и формы доступа действительно имели эту прямую привязку к таблицам/полям в базе данных.

   Большинство языков/фреймворков общего назначения имеют привязку данных в качестве отдельного компонента, не используют такую прямую привязку и обычно рассматриваются как простой универсальный дропин для контроллера в смысле шаблона MVC.

2. Это способствует подключению элементов управления видом к полям данных во время разработки. По моему опыту, это приводит к тому, что жизненно важный код (привязка столбца A к полю X) становится неясным и скрытым в каком-то файле конструктора. IMO этот код должен быть явным и in-your-face, так что его легко изменить и увидеть, что происходит, без необходимости использовать неуклюжий интерфейс конструктора.

   Я полагаю, вы говорите о связывании в WinForms году?

   Мой опыт работы с формами win пришел очень давно, так что я могу быть довольно устаревшим здесь. Это действительно удобная функция,и я бы сильно возражал против нее, если только вы не пишете действительно простые модальные интерфейсы стиля context CRUD.

3. В отношении точки #1 эта прямая привязка затрудняет выделение каждого компонента (вид, модель, controller/presenter) и модульный тест).

   Опять же-предполагая вид (виджет в WinFoms?) связано вместе с привязкой к базе данных осознанием, вы правы.

Но для меня привязка данных становится гораздо большим препятствием при работе с большим приложением, ориентированным на данные.

Совсем наоборот - если привязка данных реализована как самостоятельный компонент (напр. привязки в Cocoa или JFace DataBinding, или JGoodies Binding), который действует как контроллер между представлением и моделью, заботясь обо всех мелочах обработки событий, преобразования и проверки, то это просто намного проще использовать, изменять и заменять, чем ваш пользовательский код контроллера, делающий то же самое.

Единственным недостатком универсальной структуры привязки данных является то, что если привязка отключена и/или неправильно настроена, то взаимодействие между связанными частями просто заведомо трудно отладить из-за уровня абстракции внутри кода привязки данных... Так что лучше не делайте никаких ошибок! ;)

Я использовал привязку данных в некоторых довольно больших системах и обнаружил, что она работает довольно хорошо.

Хотя, кажется, я все делаю немного иначе, чем ты ... ...

Я не привязываюсь к модели, а к выделенному классу представления, который работает как адаптер между структурой модели и тем, что мне нужно на экране. Это включает в себя такие вещи, как предоставление выбора для comboboxes & listviews и так далее. ...

Я никогда не настраивал привязку с помощью UI. Вместо этого у меня есть один метод (обычно называемый Bind() или BindXYZ() ), который объединяет все в одном месте.

Моя модель остается агностической, ничего не зная о привязке данных; мой докладчик придерживается координат рабочего процесса, для которых он предназначен; мои представления теперь также являются простыми классами (легко тестируемыми), которые инкапсулируют мое поведение UI (включена ли кнопка X и т. д.), а фактический UI низведен до простого помощника на стороне.

@Point 1: разве механизм привязки данных не является контроллером, если вы действительно хотите думать в шаблонах? Вы просто не программируете его сами, в чем и заключается весь смысл использования привязки данных в первую очередь.

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

1. Утверждение о том, что привязка данных позволяет создавать бизнес и презентацию в изоляции друг от друга, на самом деле довольно далеко от того, что происходит на самом деле. Обычно недостатки в технологиях становятся очевидными, и тогда все, что вы сделали, это отделили UI от UI-специфического бизнеса, и в результате разделение часто становится гораздо более громоздким, чем подход all-in-one.

2. Большинство механизмов привязки данных (HTML / WPF / или что-то еще) все делают утверждения на технической бизнес-модели, и поскольку дизайнер обычно не оснащен для этих утверждений, разработчику приходится касаться представления. Мало того, представление не должно делать утверждений о бизнес-модели-во всяком случае, это должно быть наоборот.

3. В большинстве случаев модель представления / контроллер / модель / представление-это все "coupled", а затем все, что вы действительно сделали, - это "move code around", а не просто использование кода. С учетом сказанного, я считаю, что наиболее прагматичный подход часто заключается в том, чтобы просто использовать привязку данных экономно с кодом позади и забыть о шаблонах MVVM/MVC esque.

4. Разработчики часто ставят проблемы уровня представления на модель представления, а затем начинают использовать привязку данных в качестве костыля, а не правильного подхода. например, я видел так много моделей представления, контролирующих видимость элементов UI.

5. По общему признанию, привязка данных полезна для "small systems". Я заметил, что производительность, сложность и ремонтопригодность резко страдают, поскольку приложение растет в богатстве.

6. Методы использования памяти с привязкой данных часто могут стать реальной опасностью. Например, WPF использует LOT обмана, чтобы избежать проблем, и часто разработчики все еще могут стрелять себе в ногу. Если вы не используете что-то вроде Sencha для HTML (я думаю), вы обнаружите, что ваш отпечаток ноги памяти на ваших приложениях начинает страдать даже с небольшим количеством данных.

7. Я обнаружил, что шаблоны привязки данных / UI в целом иногда имеют тенденцию немного ломаться при работе с иерархическими и ситуационными данными / представлением.

Мой личный outlook на привязке данных является то, что это инструмент, который можно легко злоупотреблять, но имеет некоторые убедительные применения. Вы можете сказать то же самое для любой техники, шаблона или руководства. Как и все, слишком много чего-то имеет тенденцию становиться проблемой. Я склоняюсь к тому, чтобы попытаться использовать наиболее прагматичный подход к ситуации. Предпочитайте последовательность, когда это прагматично, но последовательно будьте прагматичны. Другими словами, вам не придется идти по пути разработки в течение двух лет и только потом приходить к выводу, что кодовая база превратилась в гротескного вонючего мамонта в посудной лавке, полной сиротских котят. ...

№ DataBinding при правильном использовании -это хорошо™.

1. Нет; но см. #2 и #3., чтобы ведущий предоставил источники properties/well-defined для привязки. Не подвергайте модель воздействию. Ничто не обходится стороной.

2. Я согласен. Я не использую ни один из стандартных источников данных ASP.NET. Вместо этого я использую GenericDataSourceControl, который подключен к "select method", который возвращает четко определенные типы. Потребители DataSource в представлении знают только об этих типах презентаторов; не более того.

3. № Относящийся к #1. докладчик предоставляет источники properties/well-defined для привязки. Они могут быть протестированы без представления корректности (модульные тесты) и с представлением корректности приложения (интеграционные тесты).

(Мой опыт использует ASP.NET WebForms, который может отличаться от других сценариев привязки данных.)

Я использовал привязку данных на больших корпоративных системах, не связанных с фреймворком. В моем случае это было CSLA.

Он работал так хорошо,и был чрезвычайно быстр, чтобы заставить вид работать. CSLA имеет много встроенной поддержки привязки данных и проверки подлинности.

Если он сломает паттурн MVP, ну и что? если он работает лучше и быстрее, и им легче управлять. Однако я бы сказал, что это вовсе не нарушает паттурн... Вы можете подключить databind в presenter, поскольку он имеет ссылку на представление, а также на модель.

например, это то, что вы поместили бы в свой презентатор, и он заполнил бы поле списка или любой другой элемент управления, который вы хотите.

myView.list.datasource = myModel.myCollection;

• Также я хотел бы отметить, что привязка данных не должна восприниматься как подход "все или ничего". Много раз я использую привязку данных, когда у меня есть простое и легкое требование UI для сопоставления с моей объектной моделью. Однако, когда требуется специальная функциональность, я могу поместить некоторый код в презентер, чтобы создать представление, как мне это нужно, а не использовать привязку данных.

Алан

@Timbo:

И да, и нет.... но с точки зрения TDD я хотел бы оцепить каждый контроллер, чтобы я мог проверить его в изоляции. Кроме того, скажем, что мы хотим запускать каждое редактирование через EditCommand (так что мы поддерживаем отмену, например) - для меня это исключает привязку данных.

@Guy:

Да, это именно мой POV. Для меня привязка данных отлично подходит для очень простых приложений, но мы не делаем ничего из этого!

Я чувствую, что во многих фреймворках привязка данных-это просто предлог, чтобы сделать все проще. Это часто приводит, как и почти любой созданный дизайнером код, к слишком большому количеству кода, который слишком сложен и не может быть легко изменен. Я никогда не сталкивался с задачей, которую не мог бы выполнить так же хорошо (если не лучше) и, в большинстве случаев, так же быстро, связав данные, как и написав код сам.

Я вполне согласен с вами, что привязка данных имеет свои недостатки... В нашем приложении, если его не использовать тщательно, это иногда приводит нас к плохой согласованности данных...

Но могут ли быть какие-то изящные способы работы с привязкой данных с большими формами?

Пожалуйста, дайте мне Ваше мнение здесь: Как эффективно использовать фреймворк привязки