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

Question

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

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

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

Answer 1

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

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

Answer 2

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

Answer 3

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

Answer 4

Для продуктов, с которыми я работаю, настройки, создаваемые группой «Службы» для данного клиента или иногда самими клиентами, передаются остальной части команды (для материалов, которые мы сделали) и часто получают & Quot; productized & Quot; в более поздних выпусках.

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

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

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

Answer 5

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