#c# #database #entity-framework #nuget #connection-string
Вопрос:
Я создаю систему из нескольких приложений для агентства по прокату автомобилей. Все они должны подключаться к одной и той же базе данных. Там будет веб-приложение (ASP.NET), Универсальное приложение Windows (WPF) и приложение Xamarin для инспекторов на парковке.
Я решил начать с проекта библиотеки классов и использовать Entity Framework (сначала код) для создания базы данных и выполнения проверки данных, затем опубликовать ее в виде пакета NuGet на внутреннем сервере NuGet, а затем установить ее во всех трех приложениях для выполнения операций CRUD.
В моем коде у меня есть строка подключения, установленная в App.config файле проекта библиотеки классов.
<connectionStrings><add name="ZoomAutoModel" connectionString="DATA SOURCE=localhost:1521/pdbd; PASSWORD=dummyPassword; PERSIST SECURITY INFO=True; USER ID=dummyUserId" providerName="Oracle.ManagedDataAccess.Client" /></connectionStrings>
Затем я создал EntryPoint проект для тестирования своей библиотеки классов перед публикацией, я продолжал получать следующую ошибку:
System.ArgumentException: 'Connection string was not in a correct format'
Я убедился, что у меня есть библиотека в ссылках на EntryPoint проект, единственный способ запустить ее — скопировать строку подключения из проекта библиотеки классов в EntryPoint проект.
Просто для тестирования я опубликовал пакет NuGet и попытался установить его в совершенно отдельном решении, и я продолжал получать ту же ошибку, пока не скопировал строку подключения в его App.config
Где здесь моя ошибка? Я не хочу указывать строку подключения во всех файлах конфигурации приложений.
Я ссылаюсь на строку подключения в конструкторе DbContext следующим образом
public ZoomAutoModel() : base("ZoomAutoModel")
{
}
Комментарии:
1.
data source=localhost; DATA SOURCE=localhost:1521/pdbd;??? Ошибка указывает на то, что строка подключения неверна2. Конфигурационный файл библиотеки классов не компилируется в библиотеку dll и, следовательно, не следует за библиотекой в другие решения, когда на нее ссылаются. Если вы хотите, чтобы строка подключения следовала за вашей библиотекой, ее необходимо определить в другом месте.
3. Жесткое кодирование строки подключения в библиотеку-плохая идея. Вам придется изменить эту строку подключения, так или иначе. Сервер, скорее всего, изменится — большинство приложений не работают на том же сервере, что и база данных. Пароль изменится. Так же будет и пользователь. В производственной среде гораздо более вероятно использование учетной записи Windows, поэтому даже
User IDPasswordключевые слова и изменятся4. На самом деле не очень хорошая идея устанавливать строку подключения в библиотеке классов. Согласно комментарию @PanagiotisKanavos, в конечном итоге (возможно, через несколько лет) эта строка подключения должна будет измениться. Затем вам придется обновить ссылку в каждом отдельном приложении, которое ссылается на эту библиотеку (возможно, с изменениями). Если вам необходимо пойти по этому пути, я бы предложил использовать библиотеку пользовательских настроек, которая ссылается на файл глобальных настроек, хранящийся в безопасном месте в вашей внутренней сети, или, если все приложения будут запускаться с одной и той же машины, расположение на этой машине.
5. Мобильная связь тоже очень нестабильна. Мобильные приложения редко подключаются непосредственно к базе данных. Как правило, они используют очереди, протоколы передачи сообщений и синхронизацию, поэтому им не нужно подключаться напрямую. Когда они подключаются к базе данных, они ведут себя совсем по — другому-они гораздо менее разговорчивы и стараются загружать/загружать как можно больше, чтобы это не повлияло на них, если они потеряют связь позже
Ответ №1:
Все они должны подключаться к одной и той же базе данных. Там будет веб-приложение (ASP.NET), Универсальное приложение Windows (WPF) и приложение Xamarin для инспекторов на парковке.
Это никогда не сработает или, по крайней мере, не будет безопасным и масштабируемым.
Вам нужен посредник, служба веб-API, в которую все приложения отправляют свои запросы, с отдельным механизмом проверки подлинности, отличным от проверки подлинности SQL Server (о которой будет знать только ваш API).
Если вы позволите своим (мобильным) приложениям напрямую подключаться к вашей базе данных, то и ваши пользователи смогут это сделать, независимо от того, доверяете вы им или нет. Вам также придется открыть свою базу данных миру, и она будет открыта, включая всех ваших пользователей, заказы, доходы…
Вернемся к чертежной доске, это так.
Ответ на ваш фактический вопрос заключается в том, что приложение использует только свой собственный файл конфигурации, а не файл какой-либо из своих зависимостей.
Комментарии:
1. Тогда возникает проблема с подключением. Мобильные соединения по определению нестабильны, даже через Wi-Fi. Мой собственный домашний Wi-Fi в последнее время нестабилен. Протоколы баз данных были построены при условии стабильных подключений к серверу или, по крайней мере, полустабильных подключений к облачному серверу.