Блог

У меня есть VB.NET приложение, которое использует базы данных на сервере SQL. В настоящее время я тестирую приложение на том же компьютере, на котором размещен сервер.

Я подключаюсь к серверу через следующую строку подключения…

 ("Data Source = " amp; Master.CurrentIP.Text amp; ",1433;Network Library=DBMSSOCN;Initial Catalog=ExcelDM;User ID=" amp; Master.CurrentUser.Text amp; ";Password=" amp; Master.CurrentPass.Text amp; ";")
  

«Мастер.CurrentIP.Text» относится к моему общедоступному IP-адресу, а не к моему компьютеру.

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

Чтобы уточнить, на сервере включены удаленные подключения, а переадресация портов (порт # 1433) открыта как для входящих, так и для исходящих сообщений через брандмауэр Windows и настройки переадресации портов моего маршрутизатора. Все параметры TCP / IP открыты в диспетчере конфигурации SQL и т. Д.

Основываясь на ваших комментариях, я бы сделал следующие предположения:

• У вас нет никаких конфиденциальных данных, поэтому безопасность не является серьезной проблемой
• Вы собираетесь запускать это в локальной сети (локальной сети), а не через Интернет

Если это так, я бы предложил следующее:

• Вы хорошо тестируете на своем локальном компьютере — соединение будет работать одинаково по любому протоколу на локальном или удаленном, и, учитывая небольшой объем данных в кампании D amp; D, вы, вероятно, не будете беспокоиться о производительности, даже если ваше приложение очень болтает с SQL server

• Поместите информацию о вашем подключении в файл конфигурации приложения, это поддерживается в .NET framework с некоторыми вспомогательными типами, например ConfigurationManager , где вы можете получить доступ к строкам подключения следующим образом:

Конфигурационный файл:

  <connectionStrings>  
   <add name="MyConnection" providerName="System.Data.SqlClient" connectionString="server=somehostname;database=Dungeons;uid=user;password=password" />  
 </connectionStrings>  
  

c # код

  string connectionString = ConfigurationManager.ConnectionStrings["MyConnection"];
  

Смотрите здесь для получения более подробной информации:

https://learn.microsoft.com/en-us/dotnet/framework/data/adonet/connection-strings-and-configuration-files

• Поскольку ваши друзья, вероятно, не хотят связываться с вашим SQL server, и вы, вероятно, не подключены к домену Windows, я бы сказал, что вы согласны с вводом секретов (user / pass) в строку подключения в файле конфигурации

• Я бы не стал беспокоиться о том, что я сказал о безопасности Windows — в основном пользователи на клиентских компьютерах будут использоваться в качестве учетных данных для базы данных SQL, это было бы немного сложнее настроить, если вы не все подключены к домену, а не просто встраиваете пользователя / пользователя SQL в базу данных SQL.конфигурация

** Редактировать: **

В дополнение к разговору, если вы пишете приложение, к которому клиенты будут получать доступ через Интернет, использование прямого SQL-соединения обычно не лучшая идея, но это может сработать, если вы можете управлять своими клиентами / IP-адресами.

Как правило, открытие вашего SQL server в Интернет просто требует атаки — и если ваш SQL server не обновлен, это может привести к компрометации хост-компьютера.

В лучшем случае это неудобство, но если вы используете эту машину для чего-либо, кроме данных D amp; D, то вы, вероятно, не хотите, чтобы кто-то копался в ней.

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

Вы можете внести своих клиентов в белый список в SQL server / на брандмауэре. Поскольку это только друзья (скажем, 10-20 человек?), Вы можете управлять их IP-адресами без особых проблем.

Это не позволяет общему Интернету получить доступ к вашему серверу.

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

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

Вы можете использовать подход, основанный на услугах. Это то, что обычно используется для защиты веб-служб — .NET framework поддерживает это с помощью WCF (Windows Communication Foundation).

Это позволяет вам определять контракты на обслуживание, к которым может присоединиться ваш сервер / клиент.

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

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

Прочитайте о WCF здесь:

https://learn.microsoft.com/en-us/dotnet/framework/wcf/whats-wcf

Существует также подход, основанный на REST, который устанавливается на уровне HTTP, .NET framework может поддерживать это через ASP.NET веб-API.

https://dotnet.microsoft.com/apps/aspnet/apis

… короче говоря, есть несколько вариантов