Как реализовать правильно плагины в C#?
Я пытаюсь добавить плагины к своей игре и что я пытаюсь реализовать, это:
Плагины будут или моими или третья сторона, таким образом, я хотел бы решение, где катастрофический отказ плагина не будет означать отказывать главного приложения.
Методы плагинов называют очень часто (например, из-за рисования игровых объектов).
Что я нашел до сих пор:
1) http://www.codeproject.com/KB/cs/pluginsincsharp.aspx - простое понятие, которое походит на него, должно работать приятно. Так как плагины используются в моей игре для каждого раунда, который я удовлетворил бы для добавления Перезапуска () метод и если плагин больше не необходим, Разгружают () метод +, GC должен заботиться об этом.
2) http://mef.codeplex.com/Wikipage - Управляемая Платформа Расширяемости - моя программа должна работать над.NET 3.5, и я не хочу добавлять любую другую платформу отдельно, я хочу записать свою сменную систему сам. Поэтому это решение исключено.
3) Microsoft обеспечивает: http://msdn.microsoft.com/en-us/library/system.addin.aspx, но в соответствии с несколькими статьями, я считал его, очень сложен.
4) Другой AppDomains для плагинов. По словам Marc Gravell (Использование AppDomain в C#) различные AppDomains позволяют изоляцию. Разгрузка плагинов была бы легка. Что производительность загрузила бы быть? Я должен назвать методы плагинов очень часто (к графическим объектам, например).
Использование доменов приложения - http://msdn.microsoft.com/en-us/library/yb506139.aspx
Вы могли прокомментировать мои результаты? Новые подходы также одобрены!Спасибо!
4 ответа
Вы можете определить публичный интерфейс, который должен реализовывать плагин. Затем с помощью отражения вы можете просканировать папку «плагин» на предмет любых классов, реализующих этот интерфейс, а затем создать экземпляр этого класса.
Из вашего кода просто поработайте над интерфейсом и вызовите нужный метод. Что касается сбоя, всегда убедитесь, что вызовы интерфейса "плагина" всегда инкапсулированы в блоке try / catch. В случае возникновения исключения вы всегда можете удалить плагин
Обобщенный «секрет» расширяемости .NET: динамическая загрузка (для получения подключаемого модуля в домене приложений), отражение (чтобы убедиться, что он поддерживает указанные вами методы / интерфейс), атрибуты (для получения метаданных для таких вещей, как управление версиями), Late Binding (для фактического использования плагина).
Если ваши потребности в расширяемости очень просты или уникальны, вам следует подумать о том, чтобы реализовать их по-своему.
Я подозреваю, что у вас есть два требования:
- высокая производительность при рисовании объектов и
- сбой плагина не приведет к сбою вашего приложения
будут к конфликту.
Чтобы действительно гарантировать, что плагин с ошибками не приведет к сбою вашего приложения, вы должны загрузить его в отдельный AppDomain (как вы уже определили). Но вы столкнетесь с падением производительности, поскольку весь смысл доменов приложений в том, что они изолируют экземпляры объектов. Таким образом, вам, как минимум, придется сериализовать аргументы ваших плагинов (возможно, используя объекты MarshalByRef или удаленное взаимодействие). И я подозреваю, что это будет означать сериализацию хорошей части вашего игрового состояния (которая звучит так, как будто она, по крайней мере, состоит из какого-то изображения). С другой стороны, домены приложений находятся в одном пространстве процессов, поэтому накладные расходы не так велики, как межпроцессное взаимодействие.
Выгрузка плагинов так же проста, как выгрузка домена приложения.
Поскольку вам необходимо сериализовать аргументы, вы можете проверить состояние игры после того, как плагин обработает его.
Однажды я немного поигрался с доменами приложений. По моему опыту, на его создание уходит несколько секунд. Это может повлиять на количество плагинов, загружаемых в каждый домен приложений.
I Пару лет назад использовал это руководство в качестве основы для своей собственной архитектуры плагинов. Я считаю, что моя архитектура была относительно простой, но я столкнулся с некоторыми проблемами, когда дело касалось передачи сообщений между плагинами.
Если вы намереваетесь написать свою собственную архитектуру, это будет справедливо, но я бы предостерегал от этого. Это непростое мероприятие, и рано или поздно вы столкнетесь с некоторыми важными дизайнерскими соображениями, такими как передача сообщений, которые нетривиально решить (хотя, по общему признанию, одновременно довольно интересными и разочаровывающими). Огромное значение имеет использование чего-то вроде MEF, которое решает эти проблемы за вас и предоставляет действительно хороший API и фреймворк, на котором вы можете создавать свои плагины.
Кроме того, MEF будет распространяться как часть вашего приложения, поэтому вам не нужно заставлять пользователей загружать его отдельно; для них это «невидимая» зависимость и легкая для разработчиков, включая вас самих. Это также официальная архитектура подключаемых модулей для Visual Studio 2010, поэтому она имеет большой вес в сообществе .NET, и только больше разработчиков сможет писать подключаемые модули для вашего приложения, если вы тоже его используете.
Надеюсь, что в этом есть смысл.