Почему использование app.config, чтобы хранить данные конфигурации?
Я знаю, что это непростая тема, но для тех, кто хочет ответить на этот вопрос с уклоном SWIFT и хочет получить простой пример, здесь мой метод перехода для передачи данных, если вы используете переход, чтобы обойти.
Это похоже на выше, но без кнопок, меток и тому подобного. Просто передавая данные из одного представления в другое.
Настройка раскадровки
Есть три части.
- Отправитель
- The Segue
- Получатель
Это очень простой макет представления с переходом между ними.
Вот настройки для отправителя
Вот настройка для приемника.
Наконец, установка для перехода.
Контроллеры представления
Мы сохраняем это простым, поэтому никаких кнопок а не действия, мы просто перемещаем данные от отправителя к получателю при загрузке приложения и затем выводим переданное значение на консоль.
Эта страница принимает изначально загруженное значение и передает его.
import UIKit
class ViewControllerSender: UIViewController {
// THE STUFF - put some info into a variable
let favoriteMovie = "Ghost Busters"
override func viewDidAppear(animated: Bool) {
// PASS IDENTIFIER - go to the recieving view controller.
self.performSegueWithIdentifier("goToReciever", sender: self)
}
override func prepareForSegue(segue: UIStoryboardSegue, sender: AnyObject?) {
//GET REFERENCE - ...to the receiver view.
var viewControllerReceiver = segue.destinationViewController as? ViewControllerReceiver
//PASS STUFF - pass the variable along to the target.
viewControllerReceiver!.yourFavMovie = self.favoriteMovie
}
}
Эта страница просто отправляет значение переменной в консоль при загрузке. К этому моменту наш любимый фильм должен находиться в этой переменной.
import UIKit
class ViewControllerReceiver: UIViewController {
//Basic empty variable waiting for you to pass in your fantastic favorite movie.
var yourFavMovie = ""
override func viewDidLoad() {
super.viewDidLoad()
//And now we can view it in the console.
println("The Movie is \(self.yourFavMovie)")
}
}
Вот как вы можете справиться с этим, если хотите использовать переход, и у вас нет страниц под контроллером навигации.
После запуска он должен автоматически переключиться на представление получателя и передать значение от отправителя получателю, отображая это значение в консоли.
8 ответов
Основное преимущество использования app.config заключается в том, что это поддерживаемый по умолчанию способ хранения конфигурации для приложения .NET. Любой, кто использует это приложение или унаследует его от вас, когда-нибудь поблагодарит вас за использование установленных стандартов вместо того, чтобы «использовать собственные».
Кроме того, платформа .NET поддерживает использование, запись, создание и изменение файла app.config - если вы пойдете со своей собственной схемой, вам придется много раз заново изобретать колесо.
Так что я определенно рекомендую использовать app.config - это способ настройки. NET и широко распространенного и хорошо поддерживаемого стандарта.
Marc
Разделение конфигурации на разные файлы очень полезно, если в жизненном цикле вашего проекта он перемещается из одной среды в другую.
Например, когда разработчики работают над кодом, вы может захотеть, чтобы приложение указывало на поле «devsql». Когда пришло время пройти проверку качества, код развертывается на промежуточном сервере, и вы хотите, чтобы приложение указывало на 'stagingsql'.
Если вы сохраните все конфигурации в app.config, и изменение настроек было выполнено внесенный в dev-версию app.config, он будет скопирован и заткнет промежуточную версию - теперь ваши QA-специалисты указывают на базу данных dev.
Сохраняя 'database.xml' отдельно от 'app.config' , вы можете учитывать различия между различными средами,
IMHO app.config - не очень удобный способ хранения данных конфигурации, в основном по этим двум причинам:
- Вы не можете контролировать расположение файла
- Вы не можете определить свою собственную структуру для организации параметры конфигурации
Я предпочитаю использовать свой собственный класс конфигурации, который загружаю и сохраняю с помощью сериализации XML. Вы по-прежнему получаете преимущества строго типизированных настроек, и они гораздо более гибкие, поскольку вы можете определить любую структуру, которую хотите
Простота и удобочитаемость
App.config - это обычный метод в .NET для хранения конфигураций, поэтому, вероятно, другие программисты его заметят. Он хранится в XML, поэтому не будет никакой производительности по сравнению с файлом конфигурации XML.
Он также определяет местоположение для сохранения app.config (Документы и настройки / имя пользователя / Локальные настройки / Application Data / ваше приложение /) и автоматически сохраняет конфигурации в зависимости от местоположения и версии вашего приложения, чтобы позволить нескольким версиям одного и того же приложения сосуществовать.
Я бы сказал, что нет Не нужны ОБЕ app.config и пользовательский XML-файл, поэтому их сочетание может быть хорошей идеей.
Я согласен с тем, что сериализатор XML в сочетании с классом «Настройки» - отличное место для хранения ваших настроек, особенно если у вас много настраиваемых типов или объектов.
App.config используется по умолчанию и в большинстве случаев является лучшим способом обработки конфигураций приложения, учитывая, что это связано с затратами, когда вам нужно проанализировать файл, чтобы получить значения и когда файл становится достаточно большим, это становится проблемой.
Это больше проблема веб-приложений, которые имеют большие файлы web.config, каждый раз, когда вы делаете запрос, файл web.config анализируется, и это может обойтись вам дорого, вы Увидим это с некоторыми маперами ORM.
App.config хорошо поддерживает настройки подключения и ведения журнала, которые вы буду использовать почти во всех приложениях. Их переписывание может принести вам много работы. Кроме того, у вас может быть некоторая гибкость структуры, если вы используете "sectionGroup" в своем app.config.
Но прежде чем что-то делать, я хотел бы спросить парня, который создал пользовательский файл конфигурации, почему он это сделал. Есть несколько необычных ситуаций, в которых app.config вызывает некоторые проблемы, например, если вы хотите загрузить другую DLL (с собственным app.config) с помощью Assembly.Load. В этом случае вам нужно будет объединить две конфигурации в одном app.config и молиться, чтобы у них не было конфигурации с одним и тем же ключом.
В веб-тестах вы не можете перезаписать конфигурации web.config, поэтому это тоже может вызвать некоторые проблемы, в зависимости от того, что вы хотите сделать.
Но ИМХО, app.config не работает только в необычных ситуациях. заставить его работать хорошо. В большинстве случаев, я думаю, не стоит создавать свою собственную структуру конфигурации.
t заставить его работать хорошо. В большинстве случаев, я думаю, не стоит создавать свою собственную структуру конфигурации. t заставить его работать хорошо. В большинстве случаев, я думаю, не стоит создавать свою собственную структуру конфигурации.Очень легко создавать классы для определения ваших собственных разделов конфигурации в Web.config, что предоставит вам строго типизированный доступ к вашим данным конфигурации, позволит вам определить своего рода схему для конфигурации информацию и т. д. См., например, эту статью [4guysfromrolla.com] для подробностей реализации.