Лучшие практики для того, чтобы сделать приложение настраиваемым?

Question

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

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

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

Answer 1

MS работает над двумя разными платформами для этого в .NET: инфраструктура управляемой расширяемости и System.Addin.

Вероятно, наиболее часто используемый способ предоставления расширяемости приложениями - это внедрение зависимостей / инверсия управления в сочетании с разрешением типов во время выполнения. Это означает, что вы позволяете внешнему объекту «внедрять» реализацию интерфейса во время выполнения вместо привязки к конкретной реализации во время компиляции. Вашему коду не важно, написан ли ваш IRepository вашей компанией или третьей стороной. Путем кодирования с использованием интерфейсов и использования платформ DI / IOC (эта ссылка предоставляет большой обзор платформ .NET) , что позволяет легко настраивать ваше приложение.

Answer 2

Одним из способов было бы встроить язык сценариев (python и javascript, кажется, популярны) и представить значительные куски API через расширение сценариев. Возможно, вам будет проще реализовать части вашего приложения на языке сценариев.

Answer 3

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

Answer 4

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

Answer 5

Для продуктов, с которыми я работаю, настройки, которые создаются группой Сервисов для данного клиента или иногда самими клиентами, передаются остальной части команды (для материалов, которые мы сделали) и часто получают "произведено" в более поздних выпусках.

Мы поддерживаем [почти] API полного доступа, который можно использовать для выполнения [почти] всего, что может делать графический интерфейс, но в автоматическом режиме.

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

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