Следует ли возвращать BindingList из бизнес-уровня (или сервисного уровня, модели домена и т. Д.)?

Question

Мне нужен BindingList в моем пользовательском интерфейсе, чтобы обеспечить двустороннюю привязку данных между моей коллекцией и DataGridView. Однако, кажется неправильным возвращать BindingList из вашего бизнес-уровня (или уровня домена, уровня обслуживания, уровня данных и т. Д.). То есть я бы использовал BindingList только из-за требования пользовательского интерфейса, и теперь этот пользовательский интерфейс будет связан с моим уровнем домена.

Каков «правильный» развязанный способ сделать это? Должен ли я возвращать IList и затем копировать его в BindingList для целей презентации? С точки зрения реального мира, эти накладные расходы чего-нибудь стоят?

Answer 1

Копирование IList отсутствует (по крайней мере, я надеюсь, что вы на самом деле не хотите создавать копию / клон). Все, что вы обычно делаете, это создаете другую ссылку на тот же объект IList. Так что возвращение объекта IList не является чем-то плохим.

Вы можете вернуть, например, объект List и REFER к нему из bindingList (которое находится в вашем пользовательском интерфейсе).

По моему мнению, лучше возвращать объект IList (List, HashTable aso), чем BindingList, так как вы можете использовать первый в разных UI (Console, Web, Win, Service). Например. использование bindingList не будет иметь никакого преимущества в веб-приложении.

Answer 2

Я не знаю, что такое «правильный» способ, но в прошлом я использовал фреймворки, такие как CSLA, и я знаю, что он использовал BindingList и теперь ObservableCollection для бизнес-списков. Это сделало использование бизнес-объектов в пользовательском интерфейсе очень простым, поскольку пользовательский интерфейс обновлялся при добавлении или удалении элементов из списков. Если вы возвращаете IList, а затем копируете его в BindingList, вам необходимо вручную отслеживать и обрабатывать изменения в IList и переводить их в BindingList. Мое личное предпочтение - по возможности иметь бизнес-уровень с широкими возможностями, который бы использовал BindingList или ObservableCollection для представления бизнес-уровня в пользовательском интерфейсе.

Answer 3

Если вы хотите, чтобы элементы пользовательского интерфейса редактировали бизнес-модель без реализации собственных обработчиков событий, бизнес-модель должна иметь BindingList.

Каждый раз, когда вы делаете что-то вроде new BindingList<MyWidget>( list ), вы отсоединяете привязку откорневой список.Если элемент редактируется, все будет работать нормально, но добавления и удаления не будут отражены в исходном списке.

Я недавно пытался реализовать нечто подобное, нажав на событие BindingList ListChanged, котороеобновил мою модель, чтобы отразить изменения BindingList, но если модель была изменена контроллером, он не обновил BindingList в пользовательском интерфейсе.

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

Answer 4

Я думаю, что уровень домена вернет более общие типы, и будут ли они уведомлять (ObservableCollection<>) или нет (IEnumerable<> или IList<>) в соответствии с требованиями.

Уровень пользовательского интерфейса может преобразовывать их по своему желанию (или нет) в IBindingList, если им нужна эта функциональность.

Мы использовали BindableLinq с большим успехом для достижения целей уведомления / синхронизированных списков привязок (возможно, с фильтрами) на уровне пользовательского интерфейса.