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

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

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

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

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

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

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

Чего вы должны избегать / предотвращать, так это использовать эти решения «в один клик» в КРИТИЧЕСКИХ областях МИССИИ системы, где большая скорость транзакций и где качество и целостность данных имеют решающее значение. Потратьте время на то, чтобы сэкономить миллисекунды на наиболее часто используемых областях системы !!

@ Тимбо:

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

@Парень:

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

Another discussion (we've been having a lot of them these days!) in our work is whether data binding is a bad idea or not.

Personally, I think it is a Bad Thing™.

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

1. It circumvents my well architectured MVP framework - with databinding, the view communicates bi-directionally with a model. Ewww.

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

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

2. It promotes hooking up view controls to datafields at design time. In my experience, this leads to vital code (binding column A to Field X) being obscure and hidden away in some designer file. IMO this code should be explicit and in-your-face, so that it is easy to modify and see what is going on, without having to use a clunky designer interface.

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

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

3. Relating to Point #1 this direct binding makes it harder to isolate each component (view, model, controller/presenter) and unit-test.

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

But for me, databinding becomes much more of a hindrance when dealing with a large data-centric application.

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

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

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

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

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

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

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

myView.list.datasource = myModel.myCollection;

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

Алан

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

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

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

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

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

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

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

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

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

1. Нет; но см. № 2 и № 3. Сделайте так, чтобы Presenter открывал свойства / четко определенные источники для привязки. Не выставляйте модель на всеобщее обозрение. Ничего не обходится.

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

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

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

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

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

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

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

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

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

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

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

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

...