Я сделал определенный выбор в своей архитектуре, который я прошу сообщество просмотреть и прокомментировать. Я разбиваю пост на более мелкие разделы, чтобы было легче понять контекст, а затем предлагать / комментировать. Мне жаль, что сообщение длинное, но требуется для объяснения контекста.
Что я строю
Типичное бизнес-приложение, в котором есть пользователи приложения, роли безопасности, права на бизнес-операции / действия на основе ролей и несколько бизнес-модулей, таких как Получение запаса, Передача запаса, Заказ на продажу, Счет-фактура продажи, Возврат продажи, Аудит запаса и т. Д. И несколько отчеты. Приложение является приложением WinForm, поскольку оно имеет множество требований к пользовательскому интерфейсу с широкими возможностями реагирования и в большинстве случаев должно работать в автономном режиме (с локальным SQL Server).
Что я сделал
Я построил фреймворк - похвастаться нечем, а просто набором библиотек, которые удовлетворяют повторяющимся требованиям моего приложения, например, аутентификация, авторизация на основе ролей, доступ к данным, проверка, обработка исключений, ведение журнала, отслеживание статуса изменений, соответствие модели презентации и разумная слабая связь между компонентами. Нет, я не написал все с нуля, вы можете сказать, что я объединил многие вещи вместе, такие как некоторые концепции из CSLA, Мартин Фаулер для Presentation Model, блоки из Enterprise Library, Unity и т. Д., Чтобы создать набор библиотек, которые помогут моим разработчикам Быстро работать без необходимости искать в Google многие технические требования. Я пытался сохранить общую структуру, чтобы ее можно было использовать в типичных бизнес-приложениях, а также пытался следовать некоторым рекомендациям, которые будут поддерживать те же бизнес-объекты, которые также будут использоваться в среде ASP.NET MVC.
Моя нынешняя архитектура хорошо служит моим целям и создала несколько модулей (на WinForm) без особых проблем. Архитектура также хорошо подходит для создания некоторого пригодного для использования прототипа на ASP.NET MVC с тем же набором бизнес-объектов без изменения одной строки кода.
Моя дилемма
Я использовал настраиваемые бизнес-объекты, поскольку это дает мне более четкое представление ООП области проблемы в моей области решения и помогает мне визуализировать все решение в виде коллекции объектов с данными и поведением, а не с набором реляционных данных ( DataSet) и реализовать поведение (бизнес-логика, проверка правильности) и т. Д. Отдельно. Благодаря богатой поддержке привязки данных в .NET 2.0 связывание пользовательских бизнес-объектов с пользовательским интерфейсом было очень простым делом.
Сейчас, создавая свои бизнес-объекты, я все еще сталкиваюсь с дилеммой в отношении представления коллекций в бизнес-объектах. В настоящее время я использую DataSets для представления коллекций, в то время как я видел много предложений по реализации пользовательских коллекций. Например, на мой взгляд, типичный объект фактуры продажи будет содержать «позиции фактуры продажи» в качестве коллекции. Теперь теоретически я могу согласиться с тем, что каждый пункт «Счет-фактура» должен иметь свое собственное поведение вместе со своими данными (ItemCode, Name, Qty, Price и т. Д.), Но обычно управление элементами счета-фактуры продажи в счете-фактуре продажи обрабатывается продажей. Сам объект счета, например добавление / удаление предметов из коллекции. Кроме того, мы также можем поместить бизнес-логику / правила для элементов накладной на продажу, таких как «Кол-во не должно превышать заказанное количество», «Цена должна быть не более чем на 10% выше цены в Заказе на продажу» и т. Д. В самом объекте «Счет-фактура» .
С таким видением я почувствовал, что большинство дочерних коллекций бизнес-объектов может управляться самим родителем, включая добавление / удаление из коллекции и реализацию бизнес-логики для элементов коллекции, поэтому элементы коллекции не содержат ничего, кроме данные.
Кроме того, типичные коллекции представлены в пользовательском интерфейсе в гридах, где способность поддерживать привязку данных становится очень важной для любой коллекции. Внедрение пользовательской коллекции, в этом случае также означало бы, что я должен также реализовать надежную поддержку DataBinding для коллекции, что, конечно, отнимает много времени.
Теперь, учитывая поведение дочерних коллекций, реализованное в родительском объекте, и необходимость привязки данных дочерних коллекций, я выбрал DataSet для представления любой дочерней коллекции в моих бизнес-объектах. В приведенном выше примере Счета-фактуры на продажу у меня будут «Номер счета-фактуры», «Дата», «Клиент» и т. Д. В качестве атрибутов «Счета-фактуры на продажу», а «InvoiceItems» - как набор данных. Конечно, когда я говорю DataSet, это не просто набор данных, а расширенный DataSet, который поддерживает проверку бизнес-правил и ту же модель безопасности на основе ролей моей инфраструктуры, чтобы автоматически разрешать / запрещать любые бизнес-операции со строками / столбцами DataSet.
Этот подход позволил упростить управление коллекциями и привязку данных в моих бизнес-объектах, и мои разработчики могут быстро доставлять модули.
Вопросы
Считаете ли вы, что подход разумен?
Видите ли вы недостатки этого подхода?
В последнее время я думаю об использовании «Типизированных наборов данных» в качестве дочерних коллекций для упрощения представления в коде, что позволит мне писать «currentInvoice.InvoiceItems» (для DataTable) и «invoiceItem.ProductCode» или invoiceItem.Qty ', вместо' drow ["ProductCode"]. ToString () "или" (int) drow ["Qty"] "и т. д. Есть ли в этом выборе какие-либо недостатки?
Спасибо, если вы уже прочитали, и приветствие, если у вас еще есть Энергия, чтобы ответить.