Objetivo dos elementos com o nome do conextiontringName definido para LocalsqlServer?

Question

1) Por padrão, os elementos de configuração têm seus ConnectionStringName atributo definido como LocalsqlServer, e até onde eu sei, esse atributo refere -se à conexão definida no elemento em MACHING.CONFIG Arquivo.

a) Presumo aspnetdb.mdf?!

b) eu entendo aspnetdb.mdf é usado nos casos em que não criamos manualmente o banco de dados de associação ou perfil (ligando aspnet_regsql ), mas ainda não entendo o objetivo de os elementos de configuração terem ConnectionStringName atributo definido como LocalsqlServer definir? Ou seja, quando e por que eles precisariam acessar esse banco de dados?

c) O que acontece se definirmos manualmente o banco de dados de associação via aspnet_regsql E assim não use aspnetdb.mdf? Como os elementos de configuração saberão que não estamos usando aspnetdb.mdf E, portanto, tente acessar o banco de dados que criamos?

2) se quiséssemos LocalsqlServer entrada de MACHING.CONFIG Para apontar para outro arquivo de banco de dados, poderíamos fazer o seguinte:

      <connectionStrings>
        <remove name="LocalSqlServer" />
        <add name=”LocalSqlServer” ...  />
      </connectionStrings>

Eu entendo que o propósito de <remove> elemento é cancelar quaisquer elementos declarados anteriormente com o mesmo nome, mas no exemplo acima, simplesmente mudamos o atributo da conexão já existente e, como tal, MACHING.CONFIG não tem duas conexões com o mesmo nome, então por que tivemos que incluir <remove> elemento?

obrigado

Answer 1

De Artigo do elemento Connectionstrings no MSDN:

As cadeias de conexão que estão contidas no arquivo de configuração dos pais são herdadas, a menos que o elemento claro seja usado no arquivo de configuração infantil. O seguinte elemento padrão Connectionstrings está configurado no arquivo Machine.Config. Código de cópia

<connectionStrings>
    <add name="LocalSqlServer" connectionString="data source=.\SQLEXPRESS;Integrated
        Security=SSPI;AttachDBFilename=|DataDirectory|aspnetdb.mdf;User
        Instance=true" providerName="System.Data.SqlClient" />
</connectionStrings>

Portanto, se a seção do arquivo de configuração não for modificada, ele possui automaticamente essa string de conexão.

Answer 2

A convenção usada é uma das muitas que poderiam ter sido escolhidas para realizar a mesma tarefa, mas as pessoas que estavam na equipe do ASP.NET no MS na época são realmente as únicas que podem dizer "por que" esse conjunto de convenções foi usado. Meu entendimento é que o objetivo da configuração atual é facilitar o máximo possível para um iniciante começar. ou seja, execute alguns assistentes, geram automaticamente o banco de dados com configurações pré-configuradas, arraste-se alguns controles de segurança e eles têm algo para trabalhar. Como isso foi projetado para iniciantes, desenvolvedores mais experientes encontram o mesmo conjunto de perguntas que você está fazendo agora, porque cavar como as peças se encaixam não é simples.

Uma das coisas que você notará no Machine.config é que todos os provedores (associação, funções, perfil etc.) usam esse nome da string de conexão localsqlserver, que novamente suporta o cenário iniciante. Portanto, para usar o seu próprio banco de dados, você precisa remover a definição padrão do localSQLServer e definir o seu. Não há um elemento de substituição na definição do arquivo de configuração, portanto, você deve usar a sequência Remover/Adicionar, que é o equivalente lógico. Ao alterar a string de conexão e deixar seu nome como LocalsqlServer, todos os provedores do Machine.Config são apontados para o seu banco de dados. Isso fornece as definições de provedor padrão para o seu banco de dados.

Agora, se você quiser personalizar as definições do provedor, poderá adicioná -las à sua própria web.config e alterar suas configurações. Nesse ponto, você pode deixar o LocalsQLServer como a string de conexão para as definições de provedor personalizado ou pode criar sua própria sequência de conexão e apontar as definições de provedor personalizado na sua própria sequência de conexão e não precisará mais se preocupar com o localSQLServer. Se você remover o LocalsQLServer de você web.config, precisará adicionar definições de provedor personalizado à sua própria web.config que referenciam sua string de banco de dados.

Espero que isto ajude,

Joe