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

Question

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

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

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

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

Спасибо.

EDIT: Думаю, я просто уточню, почему я выбрал ответ, который я сделал. Я имел в виду производственных администраторов, внешних по отношению к моей компании (т. Е. Клиента), и давал им возможность автоматизировать/скриптировать вещи проще, не требуя, чтобы они имели полное знание C# (в основном это конечные пользователи с ограниченным программированием опыт). Я думал больше о DSL. Это может быть недостижимой целью, и, по-видимому, оптимальная компромиссная стратегия, предложенная Managed Extensibility Framework.

Answer 1

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

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

Answer 2

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

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

Answer 3

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

Answer 4

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

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

Answer 5

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

Answer 6

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

Answer 7

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

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