Лучшие практики для того, чтобы сделать приложение настраиваемым?
-
06-07-2019 - |
Вопрос
Мне интересно узнать о том, как другие разработчики и архитекторы имеют дело с настройкой определенных областей своих приложений для определенных сайтов. Вызовы осуществляются заказчиком до и после обработки, события делают то же самое, позволяя переопределять методы бизнес-логики, используя стратегии с подключаемыми модулями, процессы, конфигурируемые данными, например, механизмы правил, сценарии и т. д.
Список можно продолжать, но я спрашиваю, кто использовал, что и каковы плюсы и минусы каждого из этих подходов, а также какие есть другие подходы.
Предполагается, что мы не создаем отдельную ветвь кода для клиента, чтобы приспособить эти настройки. Р>
Решение
MS работает над двумя разными платформами для этого в .NET: инфраструктура управляемой расширяемости и System.Addin. Р>
Вероятно, наиболее часто используемый способ предоставления расширяемости приложениями - это внедрение зависимостей / инверсия управления в сочетании с разрешением типов во время выполнения. Это означает, что вы позволяете внешнему объекту «впрыскивать» реализация интерфейса во время выполнения вместо привязки к конкретной реализации во время компиляции. Вашему коду не важно, написан ли ваш IRepository вашей компанией или третьей стороной. Путем кодирования с использованием интерфейсов и использования платформ DI / IOC (по этой ссылке представлен большой обзор платформ .NET) , что позволяет легко настраивать приложение.
Другие советы
Я хотел бы построить все модульно, а затем добавлять вещи в программу по требованию заказчика. Вы можете комбинировать это с настройками приложения, которые клиент может контролировать, позволяя им добавлять и удалять модули самостоятельно. В этом случае все, что вам нужно сделать, это установить конфигурацию по умолчанию.
Одним из способов было бы встроить язык сценариев (Python и Javascript, кажется, популярны) и представить значительную часть API через расширение сценариев. Возможно, вам будет проще реализовать части вашего приложения на языке сценариев.
Для продуктов, с которыми я работаю, настройки, создаваемые группой «Службы» для данного клиента или иногда самими клиентами, передаются остальной части команды (для материалов, которые мы сделали) и часто получают & Quot; productized & Quot; в более поздних выпусках.
Мы поддерживаем [почти] API полного доступа, который можно использовать для выполнения [почти] всего, что может делать графический интерфейс, но в автоматическом режиме. Р>
Мы призываем клиентов писать собственные сценарии, а затем делиться ими с нами. Расширение доступных видов использования продукта с помощью расширений, независимо от того, поддерживаются ли они официально или остаются инструментами сообщества, помогает сформировать доброжелательность среди вашей клиентской базы.
В случае настроек, которые мы создаем, первоначальная работа, хотя и выставляется счет конкретному клиенту, затем может быть быстро выполнена в другом месте, что позволяет нынешним и будущим пользователям более гибко использовать продукт.
Я обнаружил, что создание вашего приложения в виде библиотеки модулей, доступных на хорошем встроенном языке сценариев ( Lua , было создан именно для этого!) дает вам массу гибкости не только для пользователей; но и для себя тоже.