レポートとコーディング - 考え？

Question

最近、特定のソフトウェアシステムからポートレットにデータを取得しなければならないプロジェクトがありました。ソフトウェアはデータベースを使用していました。私は、必要なデータをモデリングしてから、Webサービスを作成して、ポートレットが情報を取得できるようにしました。

それから私は私の時間を無駄にしていることを突然私に打ち明けました。私はBIRTをつかんでポートレットに投げ込んだ後、データベースから必要なデータを直接取得したレポートを書きました。私は午後にやった。

私は報告が一方通行であることを理解していますが、これは私のことを考えさせました。レポーティングツールは、実際のデータからレポートを作成するのに非常に効果的ですが、そうしているときは単純な場合を除き、データベースに存在するデータを直接表現するのではなく、モデルをバイパスしています。

あなたは、データ集約型のアプリケーションを作成し、非自明な報告を実行する機能を必要としている場合は、アプリケーションをバイパスし、BIRTまたはCrystal Reportsのようなものを使うのですか？プロセス全体の一環として、これらのツールをどのように管理していますか？あなたが書いたレポートは、あなたのアプリケーションの一部であると考えて、そのように扱いますか？レポートはビュー、モデル、コントローラー（もしあれば）を一つの大きな混乱に包んでいます。それをどのように扱い、解釈し、計画していますか？

改訂質問：それは報告書は完璧な世界では、あなたのアプリケーションに含まれているしたいと思いますいくつかのビジネスの計算を実行することを可能としても一般的です。これは、ユーザーに返された情報の不一致につながります。一方、レポートツールを使用すると、情報を収集して表示するのが簡単になり、純粋なアプローチをとることが難しく、アプリケーション内からすべてを実行することが難しくなります。レポートのデータが通常のGUIで表示されるデータと一致するようにするための良いテクニックはありますか？

Answer 1

レポートはアプリの一部ですが、一般的にユーザーがデータキャプチャUIよりも強力なアイデアを持っているため、利便性と配信スピードのために純度を犠牲にして、コーディングは... :-)

はできるだけ早くレポートをやったように、ユーザーが別のものを欲しい色やオプションのグループまたは複数のフィルタリングやwhizzier stuffから離れて表示されます...何かを変更します...だから私は純粋さを維持する腸をバストしない。

Answer 2

報告は非常に重要です。レポートは、1つのシステムで収集された値を外部ユーザーに共有することが最も重要です。システムを直接使用していないユーザ（例えば、売上高の管理）。だから、報告は事実や数字を表示するだけではなく、コマーシャルを駆動するほぼすべてのシステムの中心的なものです。

少なくとも、より高度なシステムでは、あなたがそれらを強化することができます：あなた自身の再利用可能な「コントロール」と。たとえ正しいプラグインを使用していても、戻ってきても実装できます。システムが変更を許可しなかったため、レポートから電子メールを送信するシステムを作成しました。それは働いていた - それはそのように使用されることを意図していなかったのに。）

レポートは、アプリケーションの良い部分を作り、そしてあなたの顧客のための変更の報告をした場合、あなたは多くの自由を得ることができます。時には、最初にシステムを構築したときに思ったより多くの可能性を思いつきます。

はい、私の報告はシステムの一部です。

Answer 3

これは本当に細い線です。レポートを作成するのに時間を費やしたくない（ユーザーはいつでも変更したいと思う）が、レポートにビジネスロジックを組み込むことでロジックを複製したくないのです！Data Dynamimcsのレポート製品では、この2つのトレードオフの間に幸せな媒体ができたと思います。

ObjectDataProvider（詳細は以下のリンクを参照）を使用すると、データを取得するためにビジネスレイヤーをバイパスする必要がないように、ビジネスオブジェクト（普通の古いオブジェクト）にレポートを直接バインドできます。同時に、レポート内の他のライブラリの関数を参照して使用する方法を提供します。このようにして、ビジネスロジックの計算を行うように既に設定されたコードがある場合、それらの関数をレポート内で直接再利用することができます。この例は、以下のリンクでもご覧になれます。 http://www.datadynamics.com/Help/ddReports/ddrconDataSetAndObjectDataSource.html

レポートチュートリアルにカスタムコードを追加：http://www.datadynamics.com/Help/ddReports/ddrwlkCustomCode.html

（レポートから共有ライブラリ/ DLLを参照）カスタムアセンブリの使用（「オブジェクト・プロバイダ」セクションを参照してください）あなたのデータのためのオブジェクトへのバインディング

• ：http://www.datadynamics.com/Help/ddReports/ddrconCustomCode.html、およびhttp://www.datadynamics.com/Help/ddReports/ddrtskCreatingAnInstanceMethod.html

スコットWilleke

データダイナミクス/グレープシティ

Answer 4

私がいつもレポートで作業したのは、コードベースの一部として部分レポートを検討し、アプリケーションとともにソースに保存することです。ある状況では、アプリケーションよりもレポートが重要です。管理者は、誤った情報によって製品ラインをキャンセルしたり、キャンペーンをキャンセルしたり、営業担当者を雇ったりする可能性があるため、レポートデータからビジネス上の決断を下すことがあります。明らかに、これは管理とアプリケーションに大きく依存します。

あなたのモデルを一貫性を保つことに関して、これはやや難しい質問です。レポートとアプリケーション間の一貫したモデルを保証する1つの方法は、ストアドプロシージャ（またはビュー）を使用して、アプリケーションのアーキテクチャに応じてデータを取得することです。

Answer 5

私は、データを単に別のビューとして表示し、ビュー/モデル/コントローラを1つのビューには表示しません。

私たちのレポート（sql 2008のレポートサービスに組み込まれています）は、アプリケーション層のサービスを消費してデータを取得します（データアクセスはリポジトリにあります）。これらの関数は、単純なクエリを実行するか、レポート環境またはストアドプロシージャの悪夢となる非常に複雑な処理を処理できます。実際には、これは、あなたのシステムが成長して成長するにつれて、維持する悪夢になる、一回限りのストアドプロシージャをコーディングすることよりも時間がかかることがわかります。

レポートを単なる単なるものとして扱うかどうかは、アプリケーション設計に統合することは大きな間違いです。