Sollten eingebettete oder nicht eingebettete Berichte verwendet werden?

Wenn Sie planen, eine Anwendung mit dem Crystal Reports-SDK zu erstellen, wird eine Ihrer wichtigsten Überlegungen darin bestehen, ob eingebettete oder nicht eingebettete Berichte verwendet werden sollen. Indem Sie die SDK-Grundlagen kennen lernen, die das Einbetten von Berichten beeinflussen, können Sie leicht die optimale Struktur für Ihr Crystal Reports für Visual Studio-Projekt ermitteln.

Worin besteht der Unterschied zwischen eingebetteten und nicht eingebetteten Berichten?

Bei einem eingebetteten Bericht handelt es sich um einen Bericht, der in ein Visual Studio-Projekt importiert oder innerhalb des Projekts erstellt wurde. Sobald ein Bericht in ein Projekt eingebettet wird, wird automatisch eine Wrapperklasse für den Bericht generiert.

Ein nicht eingebetteter Bericht ist ein Bericht, der sich außerhalb des Visual Studio-Projekts befindet. Sie haben zahlreiche Möglichkeiten, auf den Bericht zuzugreifen und ihn (zwecks programmgesteuerter Interaktion mit dem Bericht) in ein Objektmodell zu laden, der Bericht verbleibt jedoch immer außerhalb des Projekts.

Wie funktioniert ein eingebetteter Bericht?

Wenn der Bericht in das Projekt importiert oder darin erstellt wird, wird automatisch eine Wrapperklasse (mit demselben Namen wie der Bericht) erstellt. Der Bericht wird innerhalb des Projekts von dieser Wrapperklasse eingeschlossen bzw. dargestellt. Danach interagiert der gesamte im Projekt enthaltene Code mit der zur Darstellung des Berichts erstellten Berichtklasse und nicht mit der ursprünglichen Berichtsdatei selbst.

Wenn Sie das Projekt kompilieren, werden sowohl der Bericht als auch die zugehörige Wrapperklasse genauso wie jede andere Projektressource in die Assembly eingebettet.

Eine Berichtwrapperklasse baut auf der allgemeinen Basisklasse ReportDocument auf. Sie erbt alle Eigenschaften und Methoden der ReportDocument-Klasse.

Anmerkung
In früheren Versionen dieser Dokumentation wurden eingebettete Berichte als Berichte mit "strikter Typisierung" bezeichnet. Ab jetzt werden die einem Visual Studio-Projekt hinzugefügten bzw. darin importierten Berichte mit dem Begriff "eingebettet" beschrieben.

ReportDocument ist die Stammklasse des ReportDocument-Objektmodells.

Wie funktioniert ein nicht eingebetteter Bericht?

Der Zugriff auf einen nicht eingebetteten Bericht erfolgt immer extern. Er kann dem SDK auf unterschiedliche Weisen zugänglich gemacht werden:

• Der Bericht kann auf einem Festplattenlaufwerk unter einem Dateiverzeichnispfad abgelegt werden (siehe Binden an einen Dateiverzeichnispfad im Code).
• Der Bericht kann als Berichtswebdienst verfügbar gemacht werden (siehe Binden an die URL eines Berichtswebdienstes).
• Der Bericht kann Bestandteil einer Berichtgruppe sein, die über Crystal Services verfügbar gemacht wird (siehe CrystalReportViewer-Bindungsszenarien mit Verwendung von Crystal Services).

Da nicht eingebettete Berichte niemals in das Projekt importiert werden, wird für sie (im Gegensatz zu eingebetteten Berichten) auch niemals eine Berichtwrapperklasse erstellt. Der nicht eingebettete Bericht wird stattdessen zur Laufzeit in eines der Objektmodelle geladen. Dabei kommen jeweils unterschiedliche Verfahren zur Anwendung:

• Das ReportDocument-Objektmodell verwendet die ReportDocument.Load()-Methode, um den Bericht in das ReportDocument-Objektmodell zu laden.

  Anmerkung
  Dies funktioniert nur bei Berichten, die unter einem Dateiverzeichnispfad abgelegt sind.

• Das CrystalReportViewer-Objektmodell verwendet die CrystalReportViewer.ReportSource-Eigenschaft, um den Bericht direkt an das Steuerelement zu binden.

  Anmerkung
  Generell ist die Verwendung des ReportDocument-Objektmodells vorzuziehen. Weitere Informationen finden Sie unter Welches Objektmodell sollte verwendet werden?.

Wann sollten eingebettete bzw. nicht eingebettete Berichte verwendet werden?

Falls Sie die Projektbereitstellung vereinfachen möchten, sollten Sie eingebettete Berichte verwenden. Die Anzahl der verwendeten Dateien reduziert sich, und auch das Risiko, dass Dateien unter dem falschen Dateiverzeichnispfad gespeichert werden, wird gemindert. Diese Lösung bietet auch insofern eine höhere Sicherheit, als Berichte keinen Änderungen ausgesetzt sind.

Auch für Anwender, die in der Entwicklung und Bereitstellung von Crystal Reports-Berichten mit Visual Studio noch unerfahren sind, ist es wesentlich einfacher, die Berichte einzubetten. Direkt nach dem Einbetten sind die Berichte immer als Klasse im Projekt vorhanden, sie sind über IntelliSense verfügbar, und sie werden im Objektbrowser angezeigt. Sie müssen sich daher keine Gedanken machen, ob Berichte im Dateiverzeichnis verschoben oder gelöscht oder ob der Pfad richtig geschrieben wurde.

Eingebettete Berichte sind zwar einfacher zu verwalten und bieten Sicherheit, verursachen aber gleichzeitig einen größeren Arbeitsaufwand. Sie können nicht geändert werden, ohne dass das gesamte Projekt neu kompiliert werden muss. Falls Berichte regelmäßig geändert werden müssen, sollten sie nicht eingebettet werden. Auf diese Weise werden Zugriffe und Änderungen erleichtert, ohne dass die Assemblys jedes Mal neu kompiliert werden müssen. Zusätzlich gibt es Grenzwerte für die Größe eines eingebetteten Berichts. Sehr umfangreiche Berichte werden als eingebettete Ressource kompiliert.

Darüber hinaus bieten nicht eingebettete Berichte Vorteile im Hinblick auf die Skalierbarkeit.

Websites in Crystal Reports für Visual Studio 2005 und Crystal Reports Basic für Visual Studio 2008 funktionieren nur mit nicht eingebetteten Berichten.

In den Berichtbindungsszenarien werden zahlreiche Möglichkeiten zum Binden eingebetteter und nicht eingebetteter Berichte vorgestellt (siehe Welches Berichtbindungsszenario sollte verwendet werden?). Außerdem erfahren Sie, wie Sie ReportDocument als generische Klasse für die beiden Berichttypen verwenden können. Auf diese Weise können Sie Codeänderungen auf ein Minimum reduzieren, falls Sie sich für einen anderen Ansatz entscheiden.