Совокупность настроек программы, задаваемая пользователем.
Существуют различные подходы к хранению конфигурации. Многие программы хранят настройки в текстовых файлах; особенно характерно это для UNIX-подобных систем . В Windows текстовые конфигурационные файлы так же используются и часто имеют формат .ini . Несмотря на то, что почти во всех случаях эти файлы можно редактировать вручную, во многих случаях для этого создаётся специальный интерфейс (который может быть как консольный, так и графический).
Иногда в UNIX-подобных системах конфигурация задаётся на этапе сборки программы, и для её изменения программу необходимо пересобирать. Ярким примером может служить ядро Linux . Почти во всех приложениях, собираемых на основе autoconf , можно подключать или отключать те или иные внешние библиотеки через параметры к скрипту configure .
Часто для хранения конфигурации используется специальная база данных. В Windows используется реестр Windows , а в GNOME - GConf ; в обоих случаях конфигурация имеет древовидную структуру.
Источники
Напишите отзыв о статье "Конфигурация программного обеспечения"
Отрывок, характеризующий Конфигурация программного обеспечения
– Да, опять просить ее руки, быть великодушным, и тому подобное?… Да, это очень благородно, но я не способен итти sur les brisees de monsieur [итти по стопам этого господина]. – Ежели ты хочешь быть моим другом, не говори со мною никогда про эту… про всё это. Ну, прощай. Так ты передашь…Пьер вышел и пошел к старому князю и княжне Марье.
Старик казался оживленнее обыкновенного. Княжна Марья была такая же, как и всегда, но из за сочувствия к брату, Пьер видел в ней радость к тому, что свадьба ее брата расстроилась. Глядя на них, Пьер понял, какое презрение и злобу они имели все против Ростовых, понял, что нельзя было при них даже и упоминать имя той, которая могла на кого бы то ни было променять князя Андрея.
За обедом речь зашла о войне, приближение которой уже становилось очевидно. Князь Андрей не умолкая говорил и спорил то с отцом, то с Десалем, швейцарцем воспитателем, и казался оживленнее обыкновенного, тем оживлением, которого нравственную причину так хорошо знал Пьер.
В этот же вечер, Пьер поехал к Ростовым, чтобы исполнить свое поручение. Наташа была в постели, граф был в клубе, и Пьер, передав письма Соне, пошел к Марье Дмитриевне, интересовавшейся узнать о том, как князь Андрей принял известие. Через десять минут Соня вошла к Марье Дмитриевне.
Профессиональным программистам этот вопрос покажется странным. У начинающих же часто наблюдается явное непонимание важности этой возможности. При этом получается программа, похожая на каменную глыбу с высечеными на ней надписями - если захочется изменить надпись, то придётся делать новый камень.
Есть и другая крайность - когда практически всё выносится в настройки. Такие программы напоминают разлитую жидкость, а чтобы заставить её работать надо прочитать толмуд описания и настроить несколько сотен параметров, к тому же часто взаимосвязанных противоестественным образом.
Как всегда нужно найти золотую середину - с одной стороны надо постараться
удовлетворить различные прихоти пользователей, с другой стороны нужно сделать
так, чтобы большинству пользователей ничего настраивать не пришлось.
Что именно стоит настраивать.
Вот типичные примеры данных,
которые часто стоит вынести в настройки:
- Всевозможные каталоги. Например - пути до файлов данных, каталоги импорта/экспорта.
- Сетевые настройки. Имена серверов, IP-адреса, порты, имена и пароли для автоматического доступа.
- Настройки баз данных. Имена JDBC-драйверов, URL базы данных, SQL-запросы, зависимые от используемой БД.
- Настройки внешнего вида. Настройки Swing-овского Look & Feel-а, используемые шрифты, размеры, цвета, настройки горячих клавиш.
- Прочее... Любые другие вещи, которые могут менятся от пользователя к пользователю.
Например, довольно часто встречаемая ситуация - настройка соединения с БД. Начинающие программисты часто пишут нечто подобное:
Class.forName("sun.jdbc.odbc.JdbcOdbcDriver"); Connection con = DriverManager.getConnection("jdbc:odbc:MyDatabase",user,password);
Таким образом программа привязывается к конкретному JDBC драйверу. Использовать другой драйвер, например заменить мост на RMI-прокси или, в случае Oracle, OCI на Thin без перекомпиляции уже нельзя.
В объектном программировании всё представляется в виде объектов. Настройки лучше всего при этом рассматривать как свойства определённых объектов, которые хранятся в файлах конфигураций. То, каким образом эти настройки считываются и записываются тесно взаимосвязано с форматом файлов и выбраной стратегией администрирования. Рассмотрим идеальный вариант:
- Настраиваемый объект не должен содержать знаний о формате файлов и способе чтения/записи. Это позволило бы, в случае необходимости, заменить один способ другим.
- Большинство настроек должны выполняться при помощи программы (подпункт меню или отдельная программа настройки). Это сильно облегчает жизнь человека, который занимается администрированием. У большинства "юниксоидов" это может вызвать непонимание:-), но редактированием текстовых файлов в современном мире во многих случаях не обойтись.
- Должно быть установлено разумное умолчание для отсутствующих параметров. Другими словами - необходимо, чтобы большинству пользователей для запуска программы нужно было бы сделать минимум настроек. Как правило это оставляет благоприятное первое впечатление о программе, а часто именно оно - самое важное.
К сожалению этот идеальный вариант довольно трудно сделать на практике. Первое требование предполагает разработку универсального механизма сохранения объектов. Такие системы уже есть готовые, но часто они не подходят по тем или иным параметрам. Разработать же самому такую систему - далеко не каждому под силу.
Второе требование подразумевает, что для каждого объекта пишется своя панель (или диалог) для редактирования настроек. В случае большого количества объектов стоит попробовать использовать универсальные механизмы. Один из вариантов - использование стандарта JavaBeans. Этот стандарт разрабатывался для визуальных систем программирования, но, из-за сходства решаемых задач, также хорошо подходит для универсального конфигурирования. Но это тоже не самая простая задача, поэтому часто разумно предусмотреть возможность альтернативного варианта конфигурирования для пожарных случаев - например, при помощи обычных текстовых редакторов в случае использования текстовых форматов файлов.
Разумное же умолчание для параметров часто просто невозможно представить. Например, что поставить в качестве имени SMTP-сервера? В случае Unix-систем можно попробовать поставить localhost, но для Windows-мира это редко кому подойдёт.
Рассмотрим наиболее распространённые варианты: Ini-файлы.
Ini-файлы - это был самый распространённый вариант в эпоху Windows 3.x. Сейчас в виндовых программах он стал вытесняться хранением настроек в реестре. Тем не менее ini - это один из простейших вариантов хранения настроек. К сожалению довольно часто эта простота заставляет прибегать к различно рода ухищрениям. Пример типичного ini-файла:
InputDir=INPUT OutputDir=OUTPUT ArchDir=ARHIV TransferPath = a:\cour NoReceived=No Numb = 3 MenuName1 = ~N~orton ProgName1 = mousesav c:\command.com /c nc MenuName2 = Win - ~Б~локнот ProgName2 = notepad MenuName3 = Импорт из формата АБ "Инкомбанк" ProgName3 = incom.bat
В Java нет стандартного класса для чтения ini-файлов, но это не проблема.
Т.к. формат очень прост, его легко сделать самому:
Файлы Properties.
Этот формат распространён в Unix-мире. Он ещё проще ini-файлов, т.к. в нём отсутствует понятие секций - всё состоит из ключей и значений. Пример типичного файла:
# Database configuration Database.Driver=sun.jdbc.odbc.JdbcOdbcDriver Database.DataURL=jdbc:odbc:MyDatabase Database.Prop.user=user Database.Prop.password=password
В Java есть готовый класс для чтения/записи таких файлов
(java.util.Properties), но с ним есть некоторые проблемы. Во первых для чтения
невозможно задать кодировку файла, а это означает проблемы с русскими буквами.
Во вторых стандартная функция записи сохраняет данные в порядке следования
хэш-значений ключей, что значит - как ей больше понравится. Но это тоже легко
разрешимо - достаточно написать свою читалку/писалку. XML-файлы.
Этот формат подходит для многих целей, в том числе и для хранения настроек. XML-формат ориентирован на древовидные структуры, что довольно естественым образом отображается на объекты. Пример типичного файла:
user password
Для чтения и записи таких файлов предназначены специальные библиотеки - так называемые XML-парсеры. Таких парсеров уже сделано довольно много, так что писать его самому нет большого смысла - достаточно лишь подобрать подходящий. Для парсеров было разработано два стандартных программных интерфейса - событийный (SAX) и иерархический (DOM). Есть также и парсеры со своим интерфейсом. Размер jar-а с парсером может варьироваться от нескольких килобайт до мегабайта - в зависимости от поддерживаемых интерфейсов и возможностей.
Для XML также написано несколько библиотек для универсального сохранения
(сериализации) объектов в файлах XML. Такие библиотеки позволяют отделить
алгоритм сохранения от самого объекта, а это, как уже упоминалось, имеет много
плюсов. Сериализация.
Под термином "сериализация" понимают запись содержимого объекта в поток двоичных данных. Обычно имеется в виду универсальный алгоритм, реализуемый классами java.io.ObjectOutputStream и java.io.ObjectInputStream . Пользоваться ими просто настолько, насколько это вообще возможно - обычно достаточно лишь отметить в классе поддержку при помощи интерфейса Serializable и отметить ключевым словом transient те поля объекта, которые сохранять не нужно. Собсно и всё. :-) Пример:
public class SerialObject implements java.io.Serializable { private String name; private transient int state; public SerialObject() {} public SerialObject(String n) { name = n; } public String getName() { return name; } public void setState(int s) { state = s; } }Запись объектов:
SerialObject o = ...; OutputStream os = ...; ObjectOutputStream oos = new ObjectOutputStream(os); oos.writeObject(o);Чтение объектов:
InputStream is = ...; ObjectInputStream ois = new ObjectInputStream(is); SerialObject o = (SerialObject)ois.readObject();Использование сериализации - это один из самых простых вариантов по реализации, но и у него есть свои недостатки. Получаемые файлы являются двоичными, а значит в текстовом редакторе их уже не подправить - придётся делать редактирование параметров из программы. Кроме того, необходимо следить за изменением сохраняемых объектов, дабы не нарушить совместимость при изменении и развитии программы.
Базы данных.
В базах данных можно хранить любые данные, конфигурация программы - не исключение. Это имеет смысл в нескольких случаях:
- Настройки связаны весьма сложным образом и древовидные структуры типа XML подходят плохо.
- Доступ к настройкам должен быть только у авторизованых пользователей.
- Доступ к этим данным должен быть и из других программ, например из генератора отчётов типа Crystal Reports.
Скрипты.
Использование скриптов - это один из самых экстремальных способов конфигурирования. Они позволяют добится максимальной гибкости программы за счёт вынесения логики наружу. В использовании скриптов надо тоже знать меру - в конце концов заказчик платит Вам за программу, решающую задачи, а не за ещё один интерпретатор или компилятор за который ему потребуется посадить ещё одного программиста. А то получается, как в том анекдоте - какую программу не начнёшь писать, всё компилятор получается.
Но часто без скриптов действительно тяжело. Типичные примеры - алгоритмы импорта/экспорта, алгоритмы проверок данных. Вы можете подготовить стандартный набор, а дальше настраивать скриптами под конкретные требования заказчика.
Для программ на Java в качестве скрипт-языка хорошо использовать язык Pyton в
его Java-инкарнации под названием JPyton. Там легко организовать двусторонюю
связь между программой и скриптом. Если не будет хватать скорости интерпретации,
то код на Pyton-е можно скомпилировать в байт-код - получится обычный
Java-класс. Про JPyton можно почитать на сайте http://www.jpyton.org/ или в новой книжке Брюса Эккеля
Thinking In Patterns with Java (доступна на http://www.bruceeckel.com/).
Пример программы с конфигурацией в XML.
В качестве примера можете посмотреть простенькую программы, использующей XML-файл в качестве конфигурационного. Сохраняемые параметры можно редактировать как из программы, так при помощи текстового редактора.
Пример содержимого конфигурационного файла:
Просто строчка Вторая строчка
В качестве XML-парсера используется Sun-овский парсер в режиме DOM. На таком простом примере не видно особых преимуществ формата XML над теми же файлами properties. Они становятся заметны только в достаточно сложных программах, где становится необходимо хранить списки однотипных параметров или же содержимое объектов с уровнем вложенности два или более.
На всех уровнях тестирования применяются методы:
- функционального тестирования , обеспечивающие проверку реализации функций, которые определены в требованиях, а также правильность их выполнения;
- регрессионного тестирования , ориентированные на повторное выборочное тестирование системы или ее компонентов после внесения в них изменений на тех же тестах, что и до модификации;
- тестирования эффективности , проверяющие производительность, пропускную способность, максимальный объем данных и системные ограничения в соответствии со спецификациями требований;
- стресс-тестирования , проверяющие поведение системы при максимально допустимой нагрузке или при ее превышении;
- альфа и бета тестирования , выполняющие внутреннее тестирование кодов системы и внешнее тестирование интерфейсов. Альфа - это внутреннее тестирование (функций и алгоритмов), а бета - внешнее (взаимосвязей с другими системами и средой)
- конфигурационного тестирования , проверяющие структуры и идентификации системы на различных наборах данных, а также работу системы на различных конфигурациях аппаратуры и оборудования.
К методам тестирования относятся также методы проведения испытаний ПО, проверки реализации требований и обеспечения параметров настройки и размещения компонентов ПО на заданном количестве и типах компьютеров, среды и ОС.
Техники тестирования базируются на некоторых теоретических и практических положениях, например, на природе подхода к проектированию (компонентного, объектно-ориентированного, сервисного и т.п.), а также на следующих данных:
- информация о структуре ПО или системы в документации ("белый ящик" ) ;
- подбор тестовых наборов данных для проверки правильности работы компонентов и системы в целом без знания их структуры ("черный ящик");
- анализ граничных значений, таблиц принятия решений, потоков данных, статистики отказов и др.;
- блок-схемы построения программ и составления наборов тестов для покрытия системы этими тестами;
- обнаруженные и зафиксированные в таблицах системы дефекты, пред- и постусловия выполнения, структурные характеристики системы (количество модулей, объем данных и др.).
Метрики тестирования .Для измерения результатов тестирования ПО, а также при проведении анализа качества используются метрики. Измерение как часть планирования и разработки тестов базируется на размере программ, их структуре и количестве обнаруженных ошибок и дефектов. Метрики тестирования обеспечивают измерение процесса планирования, проектирования и тестирования; а также результатов тестирования на основе таксономии отказов и дефектов, покрытия границ тестирования, проверки потоков данных и др. Процесс тестирования документируется и согласно стандарту IEEE 829-98 включает описание тестовых документов, их связи между собой и с задачами тестирования. Без документации по процессу тестирования невозможно провести сертификацию продукта по модели СММ [1.20 ]. После завершения тестирования рассматриваются вопросы стоимости и оценки рисков, вызванных сбоями или недостаточно надежной работой системы. Стоимость тестирования является одним из ограничений, на основе которого принимается решение о прекращении или его продолжении.
Управление тестированием :
- планирование процесса тестирования (составление планов, тестов, наборов данных) и оценивание показателей качества ПО;
- проведение тестирования компонентов повторного использования и паттернов как основных объектов сборки ПО;
- генерация необходимых тестовых сценариев, соответствующих среде выполнения ПО;
- верификация правильности реализации системы и валидация правильности реализации требований к ПО;
- сбор данных об отказах, ошибках и др. непредвиденных ситуациях при выполнении программного продукта;
- подготовка отчетов по результатам тестирования и оценка характеристик системы.
Заметим, что стандарт ISO/IEC 12207 и гармонизированный ГОСТ 12207 не выделяет деятельность по тестированию в качестве самостоятельного процесса, а рассматривает тестирование как неотъемлемую часть всего ЖЦ.
1.1.5. Сопровождение ПО (Software maintenance)
Сопровождение ПО - совокупность действий по обеспечению работы ПО, а также по внесению изменений в случае обнаружения ошибок в процессе эксплуатации, по адаптации ПО к новой среде функционирования, а также по повышению производительности или улучшению других характеристик ПО. В связи с решением проблемы 2000 года сопровождение стало рассматриваться как более важный процесс, который должны осуществлять разработчики. Новая версия системы должна решать те же самые задачи, иметь план переноса информации в другие обновленные БД и учета стоимости сопровождения. Сопровождение (в соответствии со стандартами ISO/IEC 12207 и ISO/IEC 14764) считается модификацией программного продукта в процессе эксплуатации при условии сохранения целостности продукта.
Область знаний "Сопровождение ПО ( Software maintenance )" состоит из следующих разделов:
- основные концепции (Basic Concepts),
- процесс сопровождения (Process Maintenance),
- ключевые вопросы сопровождения ПО (key Issue in Software Maintenance ) ,
- техники сопровождения (Techniques for Maintenance)
Сопровождение рассматривается с точки зрения удовлетворения требований к созданному ПО, корректности его выполнения, процессов обучения и оперативного учета процесса сопровождения.
Основные концепции описывают базовые определения и терминологию, подходы к эволюции и сопровождению ПО, а также к оценке стоимости сопровождения и др.
К основным концепциям можно отнести ЖЦ ПО (стандарт ISO/IEC 12207) и составление документации. Главное назначение этой области знаний состоит в выполнении готовой программной системы, фиксации возникающих ошибок при выполнении, исследовании причин ошибок, анализа необходимости модификации системы в целях устранения ошибок, оценки стоимости работ по проведению изменений функций и системы в целом. Рассматриваются проблемы, связанные с увеличением сложности продукта при большом количестве изменений и методы ее преодоления.
Процесс сопровождения включает : модели процесса сопровождения и планирование деятельности людей, которые проводят запуск ПО, проверку правильности его выполнения и внесения в него изменений. Процесс сопровождения согласно стандарту ISO/IEC 14764 проводится путем:
- корректировки, т.е. изменения продукта для устранения обнаруженных ошибок или нереализованных задач;
- адаптации, т.е. настройки продукта в изменившихся условиях эксплуатации или в новой среде выполнения данного ПО;
- улучшения, т.е. эволюционного изменения продукта для повышения производительности или уровня сопровождения;
- проверки ПО с целью поиска и исправления ошибок, обнаруженных при эксплуатации системы.
Ключевые вопросы сопровождения ПО .Основными из этих вопросов являются управленческие, измерительные и стоимостные. Сущность управленческих вопросов состоит в контроле ПО в процессе модификации, совершенствовании функций и недопущении снижения производительности системы. Вопросы измерения связаны с оценкой характеристик системы после ее модификации, а также повторного тестирования и оценки показателей качества. Стоимостные вопросы связаны с оценкой затрат на сопровождение ПО в зависимости от его типа, квалификации персонала, платформы и др. Знание этих факторов часто позволяет уменьшить затраты.
Эволюция ПО .Известный специалист в области ПО Дж. Леман (1970г.) предложил рассматривать сопровождение как эволюционную разработку программных систем, поскольку сданная в эксплуатацию система не всегда является полностью завершенной, ее надо изменять в течение срока эксплуатации. В результате программная система становится более сложной и плохо управляемой, возникает проблема уменьшения ее сложности. К технологиям эволюции ПО относятся реинженерия, реверсная инженерия и рефакторинг.
Реинженерия - это усовершенствование устаревшего ПО путем его реорганизации или реструктуризации, а также перепрограммированием отдельных элементов или настройки параметров на другую платформу или среду выполнения с сохранением удобства его сопровождения.
Реверсная инженерия состоит в восстановлении спецификации ( графов вызовов , потоков данных и др.) по полученному коду системы для наблюдения за ней на более высоком уровне. Восстанавливается идентификация программных компонентов и связей между ними для обеспечения перепрограммирования системы к новой форме.
Чаще всего реверсная инженерия применяется после того, как в код ПО было внесено много изменений и оно стало неуправляемым.
Рефакторинг - это реорганизация кода для улучшения характеристик и показателей качества объектно-ориентированных и компонентных программ без изменения их поведения. Этот процесс реализуется путем постепенного изменения отдельных операций над текстами, интерфейсами, средой программирования и выполнения ПО, а также настройки или внесения изменений в инструментальные средства поддержки ПО. Если сохраняется форма существующей системы при изменении, то рефакторинг - один из вариантов реверсной инженерии.
1.1.6. Управление конфигурацией ПО
Управление конфигурацией (Software Configuration Management - SCM ) состоит в идентификации компонентов системы, определении функциональных и физических характеристик аппаратного и программного обеспечения для контроля за внесением изменений и трассированием конфигурации на протяжении ЖЦ. Это управление соответствует одному из вспомогательных процессов ЖЦ (ISO/IEC 12207), выполняется техническим и административным руководством проекта; составляются отчеты об изменениях, внесенных в конфигурацию, и степени их реализации, а также проводится проверка соответствия внесенных изменений заданным требованиям.
Конфигурация системы - состав функций, программного и технического обеспечения системы, возможные их комбинации в зависимости от наличия оборудования, общесистемных средств, обозначенных в технической документации системы, и требования к продукту.
Конфигурация ПО включает набор функциональных и технических характеристик ПО, заданных в технической документации и реализованных в готовом продукте. Это сочетание разных элементов продукта вместе с заданными процедурами сборки и настройки на среду в соответствии с назначением системы. Примерами элементов конфигурации являются график разработки, проектная документация, исходный и исполняемый код, библиотека компонентов, инструкции по установке и развертыванию системы.
Область знаний "Управление конфигурацией ПО" состоит из следующих разделов:
- управление процессом конфигурации (Management of SCM Process),
- идентификация конфигурации ПО (Software Configuration Identification ),
- контроль конфигурации ПО (Software Configuration Control ),
- учет статуса (положение конфигурации в ПО или состояние) конфигурации ПО (Software Configuration Status Accounting ),
- аудит конфигурации ПО (Software Configuration Auditing ),
- управление версиями ПО и доставкой (Software Release Management and Delivery).
Управление процессом конфигурации .Это деятельность по контролю эволюции и целостности продукта при идентификации, контроле изменений и обеспечении отчетной информацией, касающейся конфигурации. Включает:
- систематическое отслеживание вносимых изменений в отдельные составные части конфигурации, выполнение аудита изменений и автоматизированного контроля за внесением изменений в конфигурацию системы или ПО;
- поддержку целостности конфигурации, ее аудит и обеспечение внесения изменений в элементы конфигурации;
- ревизию конфигурации в целях проверки наличия разработанных программных или аппаратных средств и согласования версии конфигурации с заданными требованиями;
- трассировка изменений в конфигурацию на этапах сопровождения и эксплуатации ПО.
Идентификация конфигурации ПО заключается в документировании функциональных и физических характеристик элементов конфигурации ПО, а также в оформлении технической документация на элементы конфигурации ПО.
Контроль конфигурации ПО состоит в проведении работ по координации, утверждению или отбрасыванию реализованных изменений в элементах конфигурации после формальной ее идентификации, а также в анализе входящих компонентов в конфигурацию и соответствия их идентификации.
Учет статуса или состояния конфигурации ПО проводится с помощью комплекса мероприятий, позволяющих определить степень изменения конфигурации, полученной от разработчика, а также правильность внесенных изменений в конфигурацию ПО при ее сопровождении. Информация и количественные показатели накапливаются в соответствующей БД и используются при управлении конфигурацией, составлении отчетности, оценивании качества и выполнении других процессов ЖЦ.
Аудит конфигурации - это деятельность, которая выполняется для оценки продукта и процессов на соответствие стандартам, инструкциям, планам и процедурам. Аудит определяет степень, в которой элемент конфигурации удовлетворяет заданным функциональным и физическим (аппаратным) характеристикам системы. На основе функционального и физического аудита конфигурации фиксируется базовая линия изготовленного продукта.
Управление версиями ПО - это отслеживание имеющейся версии элемента конфигурации; сборка компонентов; создание новых версий системы на основе существующих путем внесения изменений в конфигурацию; согласование версии продукта с требованиями и проведенными изменениями на этапах ЖЦ; обеспечение оперативного доступа к информации об элементах конфигурации и системы, к которым они относятся. Управление выпуском охватывает идентификацию, упаковку и передачу элементов продукта и документации заказчику. При этом используются следующие основные понятия.
Базис (baseline) - формально обозначенный набор элементов ПО, зафиксированный на этапах ЖЦ ПО.
Библиотека ПО - контролируемая коллекция объектов ПО и документации, предназначенная для облегчения процесса разработки, использования и сопровождения ПО.
Сборка ПО - объединение корректных элементов ПО и конфигурационных данных в единую исполняемую программу.
Последнее обновление: 04.09.2017
Конфигурация по умолчанию
Начиная с версии 2.0, необязательно явным образом подключать конфигурацию в проект. Инфраструктура ASP.NET Core автоматически может это сделать. Единственное ограничение состоит в том, что в качестве файла конфигурации должен выступать файл с именем appsettings.json .
Итак, добавим в проект файл appsettings.json со следующим содержимым:
{ "color": "navy", "text": "Hello ASP.NET Core 2.0!" }
Используем этот файл конфигурации в классе Startup:
Using Microsoft.AspNetCore.Builder; using Microsoft.AspNetCore.Hosting; using Microsoft.AspNetCore.Http; using Microsoft.Extensions.DependencyInjection; using Microsoft.Extensions.Configuration; namespace ConfigurationApp { public class Startup { public Startup(IConfiguration config) { AppConfiguration = config; } public IConfiguration AppConfiguration { get; set; } public void ConfigureServices(IServiceCollection services) { } public void Configure(IApplicationBuilder app) { var color = AppConfiguration["color"]; var text = AppConfiguration["text"]; app.Run(async (context) => { await context.Response.WriteAsync($"
{text}
"); }); } } }Чтобы получить конфигурацию из файла appsettings.json, достаточно передать в конструктор класса объект IConfiguration, который и будет содержать все настройки. И затем полученную конфигурацию можно использовать в приложении.
Dependency Injection
Более того конфигурация, составленная из файла appsettings.json, доступна по всему приложению, и мы можем ее получить через механизм Dependency Injection, например, в конструкторе какого-нибудь класса. Так, можно определить компонент middleware - ConfigMiddleware, который будет использовать конфигурацию:
Using System.Threading.Tasks; using Microsoft.AspNetCore.Builder; using Microsoft.AspNetCore.Http; using Microsoft.Extensions.Configuration; namespace ConfigurationApp { public class ConfigMiddleware { private readonly RequestDelegate _next; public ConfigMiddleware(RequestDelegate next, IConfiguration config) { _next = next; AppConfiguration = config; } public IConfiguration AppConfiguration { get; set; } public async Task Invoke(HttpContext context) { var color = AppConfiguration["color"]; var text = AppConfiguration["text"]; await context.Response.WriteAsync($"
{text}
"); } } }И затем использовать данный компонент в классе Startup:
Public class Startup
{
public Startup(IConfiguration configuration)
{
AppConfiguration = configuration;
}
public IConfiguration AppConfiguration { get; set; }
public void ConfigureServices(IServiceCollection services)
{
}
public void Configure(IApplicationBuilder app)
{
app.UseMiddleware
Передача конфигурации из разных источников
Однако выше приведенный способ получения конфигурации в middleware и в других классах будет работать, если в приложении определен файл appsettings.json, который и хранит все настройки. Однако если файл называется иначе, или настройки хранятся в файлах xml, ini, каких-то других источниках или просто определяются в памяти, то по умолчанию передача конфигурации в качестве сервиса работать не будет. И в этом случае необходимо явным образом указать, с каким объектом будет сопоставляться сервис IConfiguration.
Например, мы хотим хранить конфигурационные настройки в памяти и передавать их в качестве сервиса в middleware:
Public class Startup
{
public Startup()
{
var builder = new ConfigurationBuilder()
.AddInMemoryCollection(new Dictionary
В метод AddTransient() через фабрику сервисов передается объект, который будет использоваться в качестве сервиса IConfiguration. При этом код ConfigMiddleware не меняется, он также получает IConfiguration через конструктор.
Конфигурация программы. Программа разработана на базе комплексной конфигурации для 1С Предприятие 7.7 . Таким образом, если приобретается типовой продукт, необходимо наличие 1С Предприятие 7.7 Комплексная Торголя Бухгалтерия Расчет. При необходимости программа может быть внедрена в любую другую конфигурацию буквально за 1-3 дня. Конфигурация может быть как разработки 1С, так и разработки дилеров, а также разработана самостоятельно.
В этом случае необходимо объединение конфигурации клиента с поставляемой разработчиками, которое может выполнить как специалист клиента, так и дилер 1С, а также непосредственно разработчики. Программа хранит промежуточные данные в регистрах, поэтому необходимо наличие компоненты Оперативный учет. Остальные компоненты необязательны.
Важно, чтобы конфигурация в этом случае была сохранена в 1С Предприятие 7.7 . Допускается, если она была разработана в 1С Предприятие 7.5 и затем просто сохранена в новом формате. 8,12,21,22,24
Конец работы -
Эта тема принадлежит разделу:
Бюджетное управление предприятием
Это система, которая ведется в формате бюджетов по центрам ответственности. Бюджет - это точный расчет всех ресурсов предприятия для достижения.. Почему компании переходят на бюджетное управление? В условиях жесткой конкуренции, руководители компаний задумываются..
Если Вам нужно дополнительный материал на эту тему, или Вы не нашли то, что искали, рекомендуем воспользоваться поиском по нашей базе работ:
Что будем делать с полученным материалом:
Если этот материал оказался полезным ля Вас, Вы можете сохранить его на свою страничку в социальных сетях:
| Твитнуть |
Все темы данного раздела:
Преимущества бюджетирования
Преимущества бюджетирования. Бюджет вudget в переводе с английского это план или стандарт, причем не обязательно финансовый.
Так, бюджет продаж, с которого, в соответствии с маркетинговыми п
Основные виды бюджетов
Основные виды бюджетов. Существует много разновидностей бюджетов, применяемых в зависимости от структуры и размера организации, распределения полномочий, особенностей деятельности и т.п. К двум осн
Cистема бюджетного управления
Cистема бюджетного управления. Во всем мире финансовое управление в конечном счете описывается в формате трех основных отчетов, которые определяют собой систему координат для оценки финансовых резу
Планирование бюджета
Планирование бюджета. Бюджетирование представляет собой метод распределения ресурсов, охарактеризованных в количественной форме, для достижения целей, также представленных количественно. Его также
Контроль учета затрат
Контроль учета затрат. В современных условиях хозяйствования эффективность работы предприятия зависит в первую очередь от качества управления бизнесом, основа которого - система управленческого уче
Место бюджетирования в системе финансового управления и его внедрение на предприятии
Место бюджетирования в системе финансового управления и его внедрение на предприятии. Сопоставление инструментов финансового управления Таблица 1 показывает характерные особенности бюджетирования,
Описание программного продукта
Описание программного продукта. Обычно в компаниях существуют практически несвязанные контуры программной поддержки для отдельных функций и служб бухгалтерской, коммерческой, финансовой.
Час
Этапы внедрения системного решения
Этапы внедрения системного решения. Методология разбивает процесс внедрения на 8 этапов? Выяснение потребностей организации? Описание системного решения? Адаптация системы к нуждам пользователей
Заполнение констант
Заполнение констант. В момент первого запуска конфигурации появляется диалоговое окно заполнения констант программного продукта Бюджетное управление обработка ввода начальных данных. При этом часть
Настройка безопасности
Настройка безопасности. Информация, хранящаяся в программе, часто имеет конфиденциальный характер, поэтому разработчики заранее предусмотрели гибкую систему безопасности.
Можно выделить неск
Первый запуск программы
Первый запуск программы. Если в конце установки программы она не может запустить 1С Предприятие это связано с особенностями установки 1С, поэтому запустите ее через меню Программы. 2. После нормал
Работа с программой
Работа с программой. После того, как программа установлена и запущена в первый раз в монопольном режиме, ею можно полноценно пользоваться. 2. Если происходит первый запуск с компьютера, на который
Демонстрация программы
Демонстрация программы. Рекомендуется демонстрацию программы проводить через показ презентации в MS PowerPoint. Если зритель требует показа нюансов, то возможно параллельно разъяснять отдельные асп
Приобретение программы
Приобретение программы. Лицензируются и приобретаются только рабочие места модуля планирования.
То есть нужно покупать программу на то количество мест, которые будут планировать вводить доку