2013-07-24 3 views
5

Je me suis demandé quelle est la meilleure façon de faire un central SqlConnection. Donc, première chose quand j'ai commencé la programmation en C# était de mettre SqlConnection comme ceci dans chaque forme que je fait:Meilleure façon de faire SqlConnection centrale

public partial class form1 : Form 
{ 
    SqlConnection conn = new SqlConnection(
"Data Source=SERVER\\SQL;Initial Catalog=DataBase;User ID=user;Password=pass"); 

    public form1() 
    { 
     InitializeComponent(); 
     timer1.Start(); 
    } 
    } 

Maintenant, je voudrais faire une connexion central et de se débarrasser de tous ces codes dans beggining de chaque forme . Je pensais que cette classe serait la meilleure façon de le faire. Je voulais donc vous demander s'il existe une autre bonne méthode pour faire cela.

Comme je suis begginer, s'il vous plaît excuser mon niveau de description.

Nous vous remercions de votre réponse/de vos commentaires/avis.

+0

La meilleure pratique consiste généralement à avoir la chaîne de connexion dans un fichier .config. Ensuite, vous référencez la chaîne dans ce constructeur. – Renan

+0

@Renan Merci pour le commentaire, vient avec cette pratique également la possibilité d'avoir une connexion variable? Fondamentalement, je voudrais lui faire lire des informations (comme l'utilisateur, catalogue intial, mot de passe) pour SqlConnection de textBoxes. –

+0

Vous pouvez avoir plusieurs chaînes de connexion nommées dans un fichier. Ensuite, vous utilisez une certaine logique dans votre code pour choisir le plus approprié. Alors oui, vous pouvez modifier les chaînes que vous utilisez. – Renan

Répondre

3

La méthode standard de stockage des informations SqlConnection consiste à utiliser un fichier de configuration tel que app.config ou web.config. Vous pouvez également créer votre propre fichier de configuration.

Après cela, utilisez ConfigurationManager.ConnectionStrings [ « YourConnectionStringName »]. ConnectionString plutôt que les paramètres de connexion hardcoded

0

Si vous voulez juste un objet de connexion SQL globalement accessible, puis il suffit de regarder dans les classes statiques, comme vous pouvez avoir un classe statique avec un constructeur statique afin que tout puisse y accéder.

Je ne ferais pas cela, mais si vous apprenez, il n'y a pas de mal, mais les statiques/singletons sont souvent utilisés pour avoir 1 instance d'un composant dans une application.

// Simple static example 
public static class DatabaseConnection 
{ 
    public static IDBConnection ActiveConnection {get; private set;} 

    static DatabaseConnection() 
    { 
     var myConnectionString = // get your connection string; 
     ActiveConnection = new SqlConnection(myConnectionString); 
     ActiveConnection.Connect(); // This is bad, really should be in a using 
    } 
} 

// Simple static usage 
DatabaseConnection.ActiveConnection.ExecuteQuery(blah); 

Le problème est que vous contrôlerez l'habitude de cette ressource, et fermez wont la connexion jusqu'à ce que l'application ferme qui est une mauvaise pratique, vous pouvez donc améliorer ce peu, tout en conservant votre fonctionnalité globalement accessible.

// Better static example using actions 
public static class DatabaseConnection 
{ 
    private static string connectionString; 

    public static void OpenConnectionAnd(Action<Connection> actionToDo) 
    { 
     using(var connection = new SqlConnection(this.connectionString)) 
     { 
      connection.Connect(); 
      actionToDo.Invoke(connection); 
      connection.Disconnect(); 
     }  
    } 

    static DatabaseConnection() 
    { 
     this.connectionString = // get your connection string; 
    } 
} 

// Better usage example 
DatabaseConnection.OpenConnectionAnd(x => x.Execute(blah)); 

Syntaxe ne peut pas être 100% à droite que je suis juste au-dessus de l'écriture du haut de ma tête, mais devrait être assez proche pour être utile.

0

Vous pouvez regarder dans le Data Access Pattern pour gérer tous les interfaçage avec sql.

Cette approche est généralement recommandée. Par conséquent, plusieurs formulaires (ou tout autre cas) peuvent accéder aux mêmes méthodes de récupération et de stockage des données.

Here est une question sur la façon de l'utiliser (avec des réponses).

1

N'ayez pas une connexion globale car si elle se casse (en raison d'une erreur réseau), votre application cesse de fonctionner. En outre, vous pouvez avoir des bogues avec des transactions accidentellement laissées ouvertes ou des options définies par d'autres parties de votre code. Au lieu de cela, stocker la chaîne de connexion globalement et créer une nouvelle connexion chaque fois que vous en avez besoin. Il est préférable de commencer frais chaque fois.

static class ConnectionFactory 
{ 
public static SqlConnection Create() { 
    return new SqlConnection(GetConnectionStringSomehow()); 
} 
} 

utiliser comme ceci:

using (var conn = ConnectionFactory.Create()) { 
//do something 
} 
+0

Merci pour votre réponse, donc il y a moyen de "créer" SqlConnection existant à partir d'un autre formulaire par exemple? –

+0

Vous ne savez pas ce que signifie "créer une connexion existante" ... Vous pouvez appeler ConnectionFactory.Créez n'importe où, y compris à partir d'autres formulaires. Voir l'exemple de code mis à jour. – usr

2

En utilisant une connexion « centrale » est fortement déconseillée, car il se casse plusieurs modèles qui ADO.NET outils. Il est beaucoup plus facile d'utiliser une "chaîne de connexion centrale" à la place. Si vous voulez utiliser des paramètres dynamiques, vous pouvez regarder dans la classe "SqlConnectionStringBuilder".

ADO.NET est construit autour d'un modèle "acquier tard, libérer tôt" pour les connexions DB. Toute autre tentative causera tôt ou tard des problèmes massifs (faites moi confiance, voyez-le plusieurs fois: erreurs réseau/erreurs de transaction/erreurs de concurrence/erreurs de multithreading ...)

ADO.NET utilise un "pool de connexions" pour la connexion physique réelle à la base de données. Donc, à moins d'utiliser des chaînes de connexion différentes pour chaque connexion, vous devriez quand même vous retrouver avec une connexion. Mais puisque le "pool" gère celui-ci, il sera toujours dans un état propre quand il est (re) ouvert.

Personnellement, je préfère utiliser quelque chose comme ça pour mes chaînes de connexion:

internal static class DataSource 
{ 
    private static string _ConnectionString; 
    public static string ConnectionString 
    { 
     get 
     { 
      if (_ConnectionString == null) 
       _ConnectionString = FunctionToDynamicallyCreateConnectionstring(); 
      return _ConnectionString; 
     } 
    } 
    private static string FunctionToDynamicallyCreateConnectionstring() 
    { 
     SqlConnectionStringBuilder cb = new SqlConnectionStringBuilder(); 
     // initialize cb's properties here... 
     return cb.ToString(); 
    } 
} 

et plus tard

SqlConnection connection = new SqlConnection(DataSource.ConnectionString); 

Ce modèle veillera à ce que la chaîne même connexion exacte est utilisé thorughout mon code et que le code dynamique ne s'exécute toujours qu'une fois.

[EDIT] Dans la plupart des cas, j'évite de coder l'intégralité de la chaîne de connexion dans le fichier app.config car certains paramètres peuvent être obligatoires pour mon code et ne devraient jamais être manipulés. Je crée des paramètres personnalisés pour les propriétés "serveur" ou "base de données" que j'ai lues et assignées à ConnectionStringBuilder ...

+0

Bonjour, désolé pour le retard de vous contacter, est-il sécuritaire d'enregistrer le mot de passe et l'identifiant pour la connexion en .txt et en readline? – Marek

+0

Sûr comme dans "sécurisé" ou "stable"? La réponse serait non et oui resprective. J'utiliserais la «sécurité intégrée» chaque fois que possible, c'est-à-dire en passant l'utilisateur courant. De cette façon, l'application n'a pas besoin d'informations d'identification stockées et il est de la responsabilité de l'utilisateur ou du système d'exploitation (dans le cas de services ou de tâches planifiées) de protéger les informations d'identification. Tout cryptage ajouté aux informations d'identification (que ce soit dans la configuration de la chaîne de connexion ou dans le fichier txt) souffre du syndrome «l'application doit avoir la clé et est donc vulnérable». –

Questions connexes