Расширяемость без открытого исходного кода

Question

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

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

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

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

Спасибо.

Редактировать:Подумал, что я просто уточню, чтобы объяснить, почему я выбрал именно тот ответ, который я сделал.Я имел в виду администраторов производства, внешних по отношению к моей компании (т.е.клиент), и предоставляя им какой-то способ автоматизации / написания сценариев более простым способом, не требуя от них полного знания c # (в основном это конечные пользователи с ограниченным опытом программирования) - я больше думал о DSL.Это может быть недостижимой целью, и платформа управляемой расширяемости, по-видимому, предлагает наилучший компромисс на данный момент.

Answer 1

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

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

Answer 2

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

Answer 3

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

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

Answer 4

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

Answer 5

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

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

Answer 6

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

Answer 7

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

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