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

Question

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

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

Answer 1

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

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

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

Answer 2

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

Answer 3

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

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

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

Answer 4

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

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

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

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