Архитектурный выбор о представлении коллекций в бизнес-объектах

Question

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

Что я строить

Типичных бизнеса-приложения, где есть пользователи приложения, функции безопасности, бизнес-операция/право действий на основе ролей и несколько бизнес-модулей, как Stock получать, перемещение запаса, продажу заказа, продажу счета-фактуры, Продажа Возврат, Проверка запасов и т. Д. И несколько отчетов. Приложение является приложением WinForm, поскольку оно имеет множество богатых и гибких требований пользовательского интерфейса и в большинстве случаев должно работать в отключенном режиме (с локальным SQL Server).

Что я сделал

Я построил базу - ничего не хвастаться, а просто набор библиотек, который служит repetative требованиям моего приложения, например, в аутентификация, авторизация на основе ролей, доступ к данным, валидация, обработка исключений, ведение журнала, отслеживание состояния изменений, соответствие модели представления и разумная свободная связь между компонентами. Нет, я не написал все с нуля, вы можете сказать, что я объединил много вещей, как некоторые концепции из CSLA, Мартина Фаулера для модели представления, блоки из Enterprise Library, Unity и т. Д., Чтобы создать набор библиотек, которые помогут моим разработчикам быть продуктивным быстро, без необходимости искать Google для многих технических требований. Я попытался сохранить общий формат, чтобы его можно было использовать в типичных бизнес-приложениях, а также попытался выполнить некоторые рекомендации, которые будут поддерживать те же бизнес-объекты, которые будут использоваться в среде ASP.NET MVC.

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

Моей дилемма

Я использовал Пользовательский Business Objects, поскольку это дает мне ясную ООП представление о масштабах проблемы в моей компетенции решения, и помогает мне визуализировать все мое решение как совокупность объектов с данными и поведением, а не с набором реляционных данных (DataSet) и реализацией поведения (бизнес-логика, проверка) и т. д. отдельно. С поддержкой богатой привязки данных в .NET 2.0 привязка Пользовательские бизнес-объекты к пользовательскому интерфейсу были легким.

Теперь, строя свои бизнес-объекты, я все еще в дилемме о представлении коллекций в бизнес-объектах. В настоящее время я использую DataSets для представления коллекций, в то время как я видел много предложений по внедрению пользовательских коллекций. Например, в моем видении типичный объект выставления счета продажи будет содержать «Сбывание счетов-фактур» в виде коллекции. Теперь, теоретически, я могу согласиться с тем, что каждый «Элемент счета-фактуры» должен иметь свое собственное поведение вместе с их данными (ItemCode, Name, Qty, Price и т. Д.), Но, как правило, управление выставленными на продажу счета-фактурами осуществляется в продаже Сам объект-фактура, например добавление/удаление элементов из коллекции. Кроме того, мы можем также поместить бизнес-логику/правила для позиций счетов-фактур, таких как «Кол-во не должно превышать заказанное количество», «Цена должна быть не более 10% выше цены в Заказе на продажу» и т. Д. Непосредственно в Салоне продажи ,

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

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

Теперь, учитывая, что поведение дочерней коллекции реализовано в родительском элементе и необходимость в DataBinding дочерних коллекций, я выбрал DataSet для представления любой дочерней коллекции в моих бизнес-объектах. В приведенном выше примере счета продажи я буду иметь «Номер счета», «Дата», «Клиент» и т. Д. В качестве атрибутов «Счета продажи», но «InvoiceItems» как DataSet. Конечно, когда я говорю DataSet, это не ванильный набор данных, а расширенный DataSet, который поддерживает проверку бизнес-правил и ту же модель безопасности на основе ролей моей инфраструктуры, чтобы автоматически разрешить/запретить любую бизнес-операцию для строк/столбцов DataSet.

Этот подход позволил упростить управление коллекциями и привязку данных в моих бизнес-объектах, и мои разработчики могут быстро доставлять модули.

Вопросы

1. Считаете ли вы, что такой подход является разумным?

2. Вы видите недостатки такого подхода?

3. Я недавно думал об использовании «типизированных наборов данных» в виде дочерних коллекций, что упрощает представление в коде, что позволит мне написать «currentInvoice.InvoiceItems» (для DataTable) и «invoiceItem.ProductCode» или «invoiceItem» .Qty 'вместо' drow ["ProductCode"]. ToString() 'или' (int) drow ["Qty"] и т. Д. Есть ли у этого выбора какие-то недостатки?

Благодарим вас, если вы уже прочитали и приветствуете, если у вас еще есть Энергия, чтобы ответить.

Answer 1

Типизированные наборы данных имеют тенденцию быть немного медленными.

Если вы используете WinForms, то я бы предложил System.ComponentModel.BindingList<T>. Это поддерживает уведомления об изменениях. Приложения WPF должны, конечно, использовать System.Collections.ObjectModel.ObservableCollection<T>. Оба расширения: Collection<T> и имеют виртуальные методы, которые вы можете подключить для добавления/удаления и т. Д.

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