Я ищу основанную на плагинах прикладную среду, сравнимую с Eclipse Plugin Framework, которая, на мой взгляд, состоит из:
- базовая инфраструктура управления плагинами (Equinox / OSGI), которая предоставляет возможность объявлять конечные точки расширения, а затем обнаруживать и загружать плагины, которые обслуживают эти конечные точки. (это отличается от Dependency Injection, но, по общему признанию, разница невелика - конфигурация сильно децентрализована, есть проблемы с версиями, это может быть связано с онлайн-хранилищем плагинов, и самое главное для меня, это должно быть легко для пользователь для добавления плагинов без необходимости знать что-либо о базовой архитектуре / файлах конфигурации)
- много слоев плагинов, которые обеспечивают базовую оболочку рабочей среды с поддержкой параллелизма, командами, списками предпочтений, меню, панелями инструментов, привязками клавиш и т. Д.
Это всего лишь царапина на поверхности RCP, которая сама по себе должна служить основой вашего приложения, которое вы создаете путем написания / сборки даже больше плагинов.
Вот что я почерпнул из интернета за последние пару дней ...
Насколько я могу судить, в мире .NET нет ничего, что могло бы дистанционно приблизиться к надежности и зрелости Eclipse RCP для Java, но есть несколько претендентов, которые неплохо справляются либо с 1, либо с 2.
(Я должен также упомянуть, что я не принял окончательного решения по WinForms против WPF, поэтому я также пытаюсь понять уровень связывания пользовательского интерфейса в любой подходящей среде. Мне также интересно узнать о связывании платформы и исходном коде лицензирование)
Я должен сказать, что материал с открытым исходным кодом, как правило, менее документирован, но проще для понимания, в то время как материал MS обычно имеет больше документации, но менее доступен, так что со многими из технологий MS мне интересно они на самом деле, в практическом смысле.
Вот библиотеки, которые я нашел:
SharpDevelop
Первое, на что я посмотрел, был SharpDevelop, который выполняет как # 1, так и # 2 в основном (без оскорблений для SharpDevelop, что достойно восхищения - я просто имею в виду более простой чем Eclipse RCP) , Тем не менее, SharpDevelop является приложением, а не фреймворком, и здесь есть основные предположения и ограничения (т. Е. Несколько связаны с WinForms). Тем не менее, есть несколько статей о CodeProject, объясняющих, как использовать его в качестве основы для приложения.
System.Addins
Похоже, что System.Addins предназначен для обеспечения надежной инфраструктуры загрузки надстроек с некоторыми сложными опциями для загрузки сборок с различными уровнями доверия и даже запуска из процесса. Похоже, что он в основном основан на коде и довольно насыщен кодом, с множеством сборок, которые служат для защиты от проблем управления версиями, и использует Guidance Automation для генерации большого количества кода.
До сих пор я не нашел много статей System.AddIns, которые иллюстрируют, как это можно использовать для создания чего-то вроде Eclipse RCP, и многие люди, похоже, ломают голову над его сложностью.
Mono.Addins
Похоже, что Mono.Addins находились под влиянием System.Addins, SharpDevelop и MonoDevelop. Похоже, он предоставляет основы из System.Addins с менее сложными вариантами загрузки плагинов, но более простыми, с регистрацией на основе атрибутов, XML-манифестами и инфраструктурой для онлайн-хранилищ плагинов.
Он содержит довольно хороший FAQ и документацию, а также довольно надежный набор примеров, которые действительно помогают нарисовать картину того, как разрабатывать архитектуру, подобную архитектуре SharpDevelop или Eclipse. В примерах для GTI используется GTK, но сама структура не связана с GTK. Похоже, что он очень хорошо справляется с задачей № 1 (загрузка надстроек) и указывает путь к № 2 (среда рабочей среды). Похоже, что Mono.Addins был создан на основе MonoDevelop, но на самом деле я не изучал, предоставляет ли MonoDevelop хорошую базовую среду рабочей среды.
Управляемая структура расширяемости
Это то, о чем все говорят в данный момент, и постепенно становится все яснее, что он делает, но я все еще довольно размыт, даже после прочтения нескольких постов на SO. Официальное слово - «он может жить бок о бок» с System.Addins. Тем не менее, он не ссылается на него и, похоже, воспроизводит некоторые из его функций. Тогда мне кажется, что это более простая и доступная альтернатива System.Addins.
Похоже, он больше похож на Mono.Addins в том смысле, что он обеспечивает связывание на основе атрибутов. Он предоставляет «каталоги», которые могут быть на основе атрибутов или на основе каталогов. Похоже, что он не предоставляет какой-либо XML или проводки на основе манифеста. До сих пор я не нашел много документации, и примеры кажутся «волшебными» и более напоминающими DI на основе атрибутов, несмотря на разъяснения, что MEF не является контейнером DI.
Его лицензия только что открылась, но она ссылается на WindowsBase - не уверен, означает ли это, что он связан с Windows.
Акрополь
Я не уверен, что это такое. Это MEF или что-то еще?
Составные блоки приложений
Существуют блоки составных приложений WPF и Winforms, которые, по-видимому, предоставляют гораздо больше среды рабочей среды. У меня очень мало опыта с ними, но они, похоже, полагаются на автоматизацию навигации, очевидно, они связаны со слоями пользовательского интерфейса. Есть несколько примеров объединения MEF с этими блоками приложения.
Я приложил все усилия, чтобы ответить на свой вопрос здесь, но на самом деле я только поверхностно разбираюсь, и у меня нет опыта ни с одной из этих платформ. Надеюсь, некоторые из вас могут добавить больше подробностей о фреймворках, с которыми у вас есть опыт работы. Было бы здорово, если бы у нас была какая-то матрица сравнения.