2009-01-20 8 views
10

J'ai une question concernant l'intégration d'objets métier développés à l'aide de Linq To Sql pour la requête de données et l'intégration avec Sql Server Reporting Services.Utilisation de Linq to SQL et Sql Reporting Services

Nous avons un ensemble d'objets métier qui interrogent deux bases de données dorsales développées avec Linq to SQL. Le SQL qui est généré est relativement dynamique (en fonction des conditions choisies par l'utilisateur) et implique plusieurs jointures, certaines internes, d'autres externes, etc. Linq to SQL a bien fonctionné pour cela. Cependant, nous avons rencontré des problèmes lorsque nous avons essayé d'implémenter des rapports avec SQL Reporting Services après le déploiement initial. Nous n'avions pas la possibilité de lier les rapports SSRS à notre couche de gestion. Ce que nous avons essentiellement fait est d'obtenir le SQL qui est exécuté à partir de SQL Profiler et de créer des procédures stockées, et d'utiliser les procédures stockées dans les rapports. Comme on peut l'imaginer, cela est devenu un problème car nous avons maintenu le code, ayant besoin de mettre à jour à la fois notre couche de gestion et la procédure stockée.

J'ai fait quelques recherches et je vois que les extensions de données personnalisées semblent être une approche pour le faire. Est-ce la solution au problème? Est-ce que quelqu'un a une meilleure approche? Existe-t-il un exemple de mise en œuvre d'une solution comme celle-ci en utilisant LINQ?

http://www.devx.com/dbzone/Article/31336

Merci

Répondre

1

Je voulais juste boucler la boucle un peu ...

Nous avons travaillé à l'implémentation avec une application LINQ to SQL, mais cela devrait également fonctionner avec EF. Fondamentalement, il est exposé dans l'article de devx énuméré ci-dessus.

Essentiellement, il est exposé dans l'article de devx énuméré ci-dessus.

http://www.devx.com/dbzone/Article/31336

Il y a plusieurs choses que nous avons rencontrés, dont un est la nécessité de « aplatir » nos données. Nous avons des routines personnalisées pour aplatir les données dans un ensemble de lignes qui peut être consommé par les rapports SSRS. Vous devrez également faire attention aux instructions d'installation dans l'article ci-dessus. Juste un rappel, nous devons utiliser les fonctions de service Web de SSRS dans notre implémentation. Si vous pouvez utiliser les rapports locaux, c'est beaucoup plus facile. Si vous êtes intéressé par les rapports locaux avec votre modèle de domaine, voici une bonne série que je viens de parcourir et qui utilise nHibernate avec SSRS.

http://codebetter.com/blogs/peter.van.ooijen/archive/2009/07/01/reporting-against-a-domain-model.aspx

http://codebetter.com/blogs/peter.van.ooijen/archive/2009/07/08/domain-driven-reports-adding-custom-code.aspx

John

+0

Vos liens vers les articles de Peter van Ooijen sont parfaits pour ce scénario. J'ai résolu mon problème en utilisant ces 2 articles seul. –

4

BTW, vous n'avez pas besoin d'utiliser Profiler pour voir le SQL généré.

var query = ( de c dans db.Customers où c.LastName = "personne" select c);

// génère la requête SQL Debug.WriteLine (query);

Retour query.ToList();

Sinon, ce que nous avons fait était d'accrocher dans la propriété Log de DataContext. Cela écrit notre SQL et les paramètres automatiquement chaque fois que nous frappons la base de données. Nous avons trouvé cela très utile pour identifier les appels de base de données inutiles.

public class DataBase : DataBaseModelDataContext 
{ 
    internal DataBase() 
    { 
    } 

    public DataBase(CommonObjects.BaseParameters param) { 
     #If (DEBUG) 
     Log = new DataBaseLoger(); 
     #endIf //(DEBUG) 
    } 

    public override void SubmitChanges(System.Data.Linq.ConflictMode failureMode) 
    { 
     System.Data.Linq.ChangeSet cs = GetChangeSet(); 

     // update audit fields for each insert 
     foreach (object entity in cs.Inserts) 
     { 
      UpdateAuditFields(entity);        
     } 

     // update audit fields for each update 
     foreach (object entity in cs.Updates) 
     { 
      UpdateAuditFields(entity); 
     } 

     base.SubmitChanges(failureMode); 
    } 
} 

public class DataBaseLoger: System.IO.TextWriter { public override encodage L'encodage {get {return nouveau System.Text.UTF8Encoding(); }}

public override void WriteLine(string value) 
    { 
     System.Diagnostics.Trace.WriteLine(System.DateTime.Now.ToString("hh:mm:ss") + " " + value, "Information"); 
    } 

    public override void WriteLine() 
    { 
     System.Diagnostics.Trace.WriteLine("", "Information");    
    } 

    public override void WriteLine(string format, params object[] arg) 
    { 
     WriteLine(string.Format(format, arg)); 
    } 
} 
+0

Merci. Nous avions un rôle de type «rédacteur de rapport» qui était une personne de type SQL par opposition au codeur, ce qui était le chemin le plus facile pour accéder au SQL. J'aime vraiment l'idée d'accrocher dans la propriété Log de DataContext si. Merci! –

4

Utilisez le contrôle ReportViewer en mode local, contre un ObjectDataSource qui utilise à son tour une classe simple avec des méthodes "Get", chaque retour IEnumerable<ClassNeededForReport>.

Exemple faire ce qui précède (moins Linq): http://msdn.microsoft.com/en-us/library/ms251692(VS.80).aspx

Il suffit d'écrire votre "Get" méthode à utiliser LINQ, en faisant éventuellement un .ToList() si nécessaire.

+0

Cela a beaucoup aidé, malheureusement, il semble être lié à des rapports côté client (RDLC). J'essaie de faire fonctionner les rapports avec les rapports côté serveur (fichiers RDC). Je fournirai plus d'informations si je suis capable de déterminer ce qui se passe. –