Связывание данных - плохая идея?

Другое обсуждение (у нас их было много в наши дни!) В нашей работе - является ли связывание данных плохой идеей или нет.

Лично я думаю, что это плохая вещь ™.

Мои причины трижды:

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

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

  3. Что касается пункта № 1, это прямое связывание усложняет изоляцию каждого компонента (вид, модель, контроллер / презентатор) и модульного тестирования.

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

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

Есть предположения?

21.08.2008 08:25:46
10 ОТВЕТОВ

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

2
21.08.2008 08:34:08

Как мы говорим в Великобритании, «это лошади для курсов»

Прежде всего, я согласен с вами! Но...

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

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

Иногда вам просто нужно «сделать это и сделать быстро». Для внутренних приложений, систем бэк-офиса и приложений для технического обслуживания, которые используются редко или являются очень динамичными (спецификация часто меняется), тогда нет достаточных оснований для создания решения Rolls Royce для этого. Лучше заставить разработчика тратить время на КРИТИЧЕСКУЮ часть системы.

Чего следует избегать / предотвращать, так это использовать эти решения в рамках «одного клика» в области MISSION CRITICAL системы, где большая область транзакций и где качество и целостность данных имеют решающее значение. Потратьте качественное время, экономя миллисекунды в наиболее часто используемых областях системы !!

5
21.08.2008 08:38:41

@Timbo:

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

@Guy:

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

0
21.08.2008 08:46:06
Привязка данных не обязательно исключает поддержку редактирования на основе команд. Существует реализация JFace DataBinding для EMF, которая отправляет все изменения через командную среду. Я не использовал это, но я слышал сообщения, что это работает отлично.
Roland Tepp 25.09.2008 13:44:40

Другое обсуждение (у нас их было много в наши дни!) В нашей работе - является ли связывание данных плохой идеей или нет.

Лично я думаю, что это плохая вещь ™.

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

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

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

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

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

    Я полагаю, вы говорите о привязке в WinForms?

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

  3. Что касается пункта № 1, это прямое связывание усложняет изоляцию каждого компонента (вид, модель, контроллер / презентатор) и модульного тестирования.

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

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

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

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

4
11.07.2012 19:18:23

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

0
18.09.2008 07:05:39

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

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

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

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

myView.list.datasource = myModel.myCollection;

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

Алан

0
18.02.2009 13:12:19

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

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

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

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

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

3
19.03.2009 19:21:47

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

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

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

0
23.05.2017 11:53:20

Нет. Привязка данных при правильном использовании - это Good Thing ™.

  1. Нет; но см. № 2 и № 3. Заставьте докладчика выставить свойства / четко определенные источники для привязки. Не подвергайте Модель воздействию. Ничего не обойти.

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

  3. Нет. Относительно # 1. Докладчик предоставляет свойства / четко определенные источники для привязки. Они могут быть проверены без представления о корректности (модульные тесты) и с точки зрения правильности применения (интеграционные тесты).

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

1
11.07.2012 19:10:59

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

  1. Утверждение о том, что привязка данных позволяет разрабатывать бизнес и презентацию независимо друг от друга, на самом деле очень далеко от того, что происходит в действительности. Обычно недостатки в технологиях становятся очевидными, и тогда все, что вам нужно сделать, это отделить пользовательский интерфейс от бизнеса, ориентированного на пользовательский интерфейс, и получающееся в результате разделение часто становится гораздо более громоздким, чем подход «все в одном».

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

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

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

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

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

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

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

...

2
10.09.2013 05:46:35