Расширяемость без открытого исходного кода - PullRequest
3 голосов
/ 24 марта 2009

Моя компания в настоящее время находится в процессе создания большого многоуровневого программного пакета на C #. Мы применили SOA-подход к структуре, и мне было интересно, есть ли у кого-нибудь какие-либо советы относительно того, как сделать его расширяемым пользователями со знаниями в области программирования.

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

Мы хотим, чтобы пользователи могли писать сценарии для выполнения общих задач, изменять макет пользовательского интерфейса (написанный в WPF) и добавлять новые функциональные возможности (т. Е. Разрешать составление диаграмм табличных данных). У кого-нибудь есть какие-либо предложения о том, как это осуществить, или кто-нибудь знает, где можно получить знания, чтобы делать такие вещи?

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

Спасибо.

РЕДАКТИРОВАТЬ: Думаю, я просто уточнить, чтобы объяснить, почему я выбрал ответ, который я сделал. Я имел в виду администраторов производства, внешних по отношению к моей компании (то есть клиента), и дал им возможность как-то проще автоматизировать / создавать сценарии, не требуя от них полного знания c # (в основном это конечные пользователи с ограниченным программированием опыт) - я больше думал о DSL. Это может быть недостижимой целью, и инфраструктура Managed Extensibility, похоже, предлагает лучший компромисс на данный момент.

Ответы [ 7 ]

8 голосов
/ 24 марта 2009

Просто используйте интерфейсы. Определите IPlugin, который должен реализовывать каждый плагин, и используйте четко определенный уровень обмена сообщениями, чтобы плагин мог вносить изменения в основную программу. Возможно, вы захотите взглянуть на такие программы, как Mediaportal или Meedios, которые сильно зависят от пользовательских плагинов.

6 голосов
/ 24 марта 2009

Как уже упоминал Стив, использование интерфейсов - это, вероятно, путь. Вам необходимо разработать набор интерфейсов, которые вы хотели бы использовать ваши клиенты, спроектировать точки входа для плагинов, а также модель взаимодействия плагинов. Наряду с предложениями Стива, вы также можете взглянуть на проект Eclipse . У них очень четкая архитектура плагинов, и хотя она написана на Java, возможно, стоит взглянуть на нее.

Другой подход может заключаться в разработке API, доступного для языка сценариев. И то и другое IronPython и Boo - это динамические языки сценариев, которые хорошо работают с C #. При таком подходе ваши клиенты могут писать сценарии для взаимодействия и расширения вашего приложения. Этот подход является немного более легким решением по сравнению с полной системой плагинов.

4 голосов
/ 24 марта 2009

Я бы взглянул на инициативу MEF от Microsoft. Это фреймворк, который позволяет вам расширять свои приложения. Сейчас он находится в бета-версии, но должен быть частью .Net 4.0.

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

2 голосов
/ 24 марта 2009

Открытый код не нужен ни в какой форме или форме, чтобы сделать продукт расширяемым.

1 голос
/ 24 марта 2009

Microsoft уже сделала именно это, в результате чего появились службы Reporting Services, у которых есть все атрибуты, которые вы упомянули: определяемый пользователем макет, возможность создания сценариев, диаграммы, настраиваемый пользовательский интерфейс. Это включает в себя загружаемую IDE. Доступ к исходному коду не предоставляется и не требуется, но он абсолютно завален хуками расширяемости. Отсутствие исходного кода препятствует тесной связи и способствует мышлению SOA.

1 голос
/ 24 марта 2009

Я согласен, что открытый исходный код - страшная идея в этой ситуации. Когда вы говорите об одобрении администратора производства - этот администратор в вашей компании или внешний?

Лично я хотел бы рассмотреть возможность расширения с помощью наследования (позволяя третьим сторонам создавать подклассы вашего кода без предоставления источника) и очень тщательно заданные модификаторы доступа.

0 голосов
/ 24 марта 2009

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

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

...