devexpressレポートページのxpo対BLL-DALアプローチ

Question

Webプロジェクトを開始しました。プロジェクトのSQLテーブルは、何百万ものレコードを持つ大きなテーブルであると予想されます。そして、Webアプリケーションは通常、データをユーザーに報告します。これは、Webアプリケーションが "INSERT"または "UPDATE"よりも "SELECT"を主に実行することを意味します。
私は古典的なBLL-DAL-MODELアプローチ（階層化されたアーキテクチャ）やDevexpressのXPOのようなORMを使用すべきかどうか疑問に思います。当社は小規模な多くのアプリケーションでXPOを使用しており、開発者はそれに精通しています。彼らはまた、階層化されたアーキテクチャに慣れていますが、XPOの実装が階層化されたアーキテクチャのアプローチよりも簡単です。
今、どのアプローチを選択すべきかを知りたい。 XPOとレイヤードアークの両方でデータを選択してパフォーマンステストを行う人はいますか？それとも何か考えがありますか？
ありがとうございます。

Answer 1

私はあなたの質問の理由と意味を理解していますが、XPOのような特定のテクノロジや製品をショートカットに使用することは決してレイヤードアプローチを断念するものではありません。また、EFとNHibernateのは、重ね着を必要とせずにUIから直接使用することができますが、これは意味しない良いですが、ここに私の答えを参照してください。

https://stackoverflow.com/a/7474357/559144

私はXPOを使用するか、それだけあれば、それを使用していないでしょうどちらか私がそこに記述したようにレイヤリングを行うことができます。そして、最終的にはORMであり、他の製品と同様に他から分離され、切り離される可能性が高いという大きなチャンスがあります。それでも私はDevExpressを所有しています。私は数年かけて多少変化する大きなアプリケーションには使用しません。したがって、EFやNHibernateのようなもっと標準的なものであれば、

Answer 2

XPO性能について。私は500kレコードのグリッドを持っており、正常に動作します。 1つのグリッドページに20レコードが表示されます。 ヒント（DevEx v10.2）は次のとおりです。

1. ServerModeでASPxGridViewを使用できます。デモhereをご覧ください。 ServerModeグリッドバインディングでは、次の処理を行います。
- フェッチレコード数
- 最初に512レコードIDを取得します。
- グリッドに表示するためのレコードを取得します。これは、最初のグリッドページに表示されたレコードを取得するはずですが、XPOがccaを取得するようです。 50レコード。

2.XPOは関連するオブジェクトに必要なデータも取得します。これにより多くの簡単なクエリが生成されます。これをキャッシングすることで減らすことができます。

3. XPO cachingを正常に使用しています。アプリケーションの処理速度が向上し、データベースのヒット数が減少します。すでに述べたように、私たちは500kのテーブルでそれを使用します。