2010-12-16 5 views
0

Nous avons une webapp où chaque client a sa propre base de données (environ 700 pour le moment). Dans SubSonic 2, vous deviez encapsuler chaque appel avec le SharedDBConnectionScope passant dans la bonne chaîne de connexion à utiliser, sinon vous couriez le risque qu'un thread ou client reçoive des données d'un autre thread ou client.Connexions avec de nombreuses bases de données

Dans SubSonic3 est-ce encore nécessaire? Dois-je envelopper les appels comme je l'ai fait en 2.x?

Il existe des façons simples de changer la base de données maintenant, mais ai-je encore des problèmes de threads ou puis-je supprimer l'appel à SharedDBConnectionScope?

Répondre

0

SubSonic 3 a grandement amélioré la façon de créer un fournisseur à partir de zéro ou tout simplement passer un nom et un connectionsctring:

Quelques exemples:

// Linq Templates: 
var db = new YourDB("connectionstring goes here", "System.Data.SqlClient"); 

// SimpleRepository without app.config 
IDataProvider provider = SubSonic.DataProviders.ProviderFactory.GetProvider(
    connectionString: "Server=localhost;Database=clientdb;Uid=root;", 
    providerName: "MySql.Data.MySqlClient" 
); 
IRepository repository = new SimpleRepository(provider, 
    SimpleRepositoryOptions.RunMigrations); 

Vous pouvez donc essentiellement créer un fournisseur ou un dépôt à chaque fois un client se connecte et l'utilise dans votre classe.

+0

Je comprends cela. Je règle la chaîne de connexion quand je crée l'IQuerySurface (YourDB dans votre exemple) et cela fonctionne très bien. Mais dans 2.x vous auriez des problèmes de threading, le client a verrait les données de clinet b à moins que vous n'utilisiez SharedDBConnectionScope. Je me demandais simplement si ces mêmes problèmes de thread existent ou si les changements apportés à la façon dont les fournisseurs sont créés le font. – JayGlynn

Questions connexes