Ведение двух версий библиотеки бизнес-класса - PullRequest
1 голос
/ 12 февраля 2009

Наше основное бизнес-приложение использует библиотеку (проект C #) бизнес-объектов. Доступ к данным осуществляется с помощью Wilson O / R Mapper (мы переходим на NHibernate этим летом). Приложение имеет 3 интерфейсных интерфейса: Windows Forms, ASP.NET и приложение Windows Forms, которое установлено на планшетных ПК. Три внешних интерфейса выполняют разные функции, но все они имеют доступ к основному подмножеству бизнес-классов.

Приложение для планшетного ПК - проблема. Мы стараемся ограничить объем данных, передаваемых на планшеты, чтобы сократить время, необходимое для их синхронизации с использованием репликации слиянием SQL Server. Проблема, с которой мы столкнулись, заключается в том, что мы добавляем новые функции в основное приложение, которые нам не нужно распространять на планшетные ПК, или, если речь идет о конфиденциальных данных, острая необходимость не распространять их. Некоторым из этого можно управлять с помощью репликации, но мы иногда вводим зависимости в основных бизнес-объектах, которые должны присутствовать для работы средства отображения O / R.

В идеале у нас было бы две версии библиотеки базовых бизнес-объектов, Full и Compact. Похоже, что это будет кошмар обслуживания. Есть ли стратегии для управления этим? Или альтернативы? Как Microsoft управляет полной и компактной платформой .NET?

Ответы [ 2 ]

2 голосов
/ 12 февраля 2009

Ваш вопрос говорит о Планшетном ПК , который на самом деле является просто XP, и поэтому CF на самом деле не имеет значения, но ради самого предмета вопроса мы все еще можем говорить о поддержании кода, используемого CF и FFx (если вы действительно имели в виду Windows Mobile или Windows CE).

Первое, что нужно знать, это то, что сборки CF можно перенастраивать. Это означает, что сборка CF может напрямую использоваться полнофункциональным приложением без какой-либо перекомпиляции (при условии, что она не использует никаких специфических для устройства вещей, таких как P / Invoking coredll без проверки среды выполнения, использования пространства имен WindowsMobile и т. Д.). 1005 *

Если использование ретаргетинга не поможет вам полностью, тогда вы можете справиться с maintennace, используя директивы компилятора, а также частичные классы. Даниэль Мот довольно подробно рассказывает о них в своей статье MSDN .

2 голосов
/ 12 февраля 2009

Одна вещь, которую вы можете сделать, это то, что если вы можете отдельно компилировать для каждой платформы, вы можете использовать директивы компилятора для ограничения того, что требуется платформе Tablet PC. Однако, если вы используете маппер OR, это может оказаться затруднительным.

Теперь в идеальном мире у вас на самом деле есть объекты Domain (те, которые сопоставляются с OR) с очень малой общей бизнес-логикой. Затем есть слой BO, который потребляет эти объекты домена. Если вам удалось вывести свою кодовую базу таким образом, как вы могли бы теоретически, то иметь только отдельные слои, которые вам нужно развернуть в зависимости от ваших потребностей.

Однако для меня это звучит так, будто вам нужно выполнить интеллектуальное разделение.

Что вам, вероятно, нужно сделать, это сегментировать ваш код так, чтобы BO планшетного ПК находилось в основной сборке BO BO. Затем создайте сборку расширения BO, содержащую дополнительные объекты, правила и т. Д., Необходимые для версий Winform / Web-приложений.

Таким образом, хотя в этот момент у вас будет два компонента бизнес-объекта уровня домена, у вас фактически не будет дублирования. Поскольку ваш объект BO Tablet PC также будет основой для приложения Winform / Asp.net. Тогда расширение dll будет содержать только дополнения, необходимые для больших версий hte-приложений.

Если вы последуете этому подходу, это может упростить управление. Достаточно взглянуть на это с точки зрения общего, необходимого везде, и специализированного подхода. :)

Я могу вдаваться в подробности, если хотите, просто хотел дать вам базовый хит.

...