SQL Server CLR pour intégrer la logique métier et planifier l'exécution avec SQL Server Agent

Question

J'ai la logique métier d'une application de type workflow dans une bibliothèque de classes C#, mais à la fin de chaque mois, certains processus de la bibliothèque doivent être invoqués, Je pensais que le mécanisme idéal pour invoquer cette exécution programmée est l'utilisation de l'agent SQL Server (travail SQL de préférence, même si je suis ouvert à même aller dans l'enfer SSIS si c'est absolument nécessaire), mais la question est comment puis-je invoquer le processus de la bibliothèque d'application du travail sql?

la bibliothèque d'applications est également utilisée à partir de pages asp.net, il a généralement un contexte d'application Web (web.config) avec entrée configurée et les bases de données de sortie

Je comprends que les étapes sont plus ou moins

1) Intégrer la bibliothèque de classes dans un ensemble CLR serveur SQL, signe fort clé et le déployer 2) appeler la bibliothèque

la chose que je ne suis pas clair, lors du déploiement d'un tel ensemble de CLR, ce qui se passe avec le contexte d'application Web? Comment puis-je exactement déployer le CLR avec le app.config approprié? dois-je redéployer le CLR si j'ai besoin de changer les chaînes de connexion? Je ne suis pas sûr aussi parce que le CLR doit se relier à la base de données qui l'invoque (pour des buts de table de lecture et d'écriture) mais je devine qu'il faut être très prudent pour éviter l'auto-invocation et ce genre de chose.

Answer 1

En premier lieu, ce poste finit dans « utiliser SSIS » :-P

Tant que votre bibliothèque contient des liens vers System.Web.dll Je ne pense pas que vous serez en mesure d'enregistrer dans SQL Serveur en tant qu'assemblage SQLCLR. Les assemblages SQLCLR sont très restreints et ne peuvent contenir aucune référence.

Vous pouvez déplacer des parties spécifiques de votre logique métier dans une bibliothèque de couche de présentation distincte. C'est généralement une meilleure solution que de mélanger la logique métier et les classes de présentation comme un contexte d'application web. Après cela, vous pouvez essayer de déployer votre assembly sur SQL Server.

Vous pouvez maintenant créer une deuxième bibliothèque SQLCLR contenant les procédures stockées .NET qui orchestrent vos objets métier.

Cependant, je ne vois pas vraiment l'avantage de SQLCLR, ici. Cela nécessiterait d'énormes changements dans votre code source et entraînerait plusieurs restrictions pour l'ensemble de votre application.

Mes préférences personnelles seraient Utilisez un package SSIS. Ici vous pouvez référencer n'importe quelle autre DLL et consommer ses fonctionnalités. Ou écrivez une application console .NET simple qui sera démarrée par SQL Agent. Dans les deux cas, la mise en œuvre est presque égale.

SQLCLR est spécialement conçu pour gérer les tâches spécifiques à la base de données qui touchent le mur des fonctions T-SQL possibles (et suggestives).