3

クラスで教えますが、データ アクセス テクノロジの決定に影響を与える要因を説明する必要があります。型付きデータ セット、Linq to SQL、Linq to Entities、.netTiers、LLBLGen、SQL 接続オブジェクトとコマンド オブジェクトを使用したカスタム呼び出しなど、多くのデータ アクセス方法に精通しています。一部のクライアントは、ストアド プロシージャの使用のみを許可し、それ以外については何も話しません。一部のクライアントは、まだ .NET 3.5 をインストールする準備ができていません。一部のクライアントでは、Web アプリケーションに中間の Web サービス層が必要です。ほとんどの場合、Types Data Sets と Custom Web Services を使用するか、CodeSmith で .netTiers を使用します。他に何を考えるべきですか？

4

4 に答える 4

3

覚えておくべき重要な点の 1 つは、データベースは必ずしも (分離された) アプリケーションのバッキング データ ストアであるとは限らないということです。他のアプリケーションやプロセスは、特に大規模または「エンタープライズ」データベース (またはアプリケーション) で、特に十分な時間があれば、最終的にデータベースへのアクセスを必要とする可能性があります。

次の点を考慮することが重要です。

  • ETL/ロード/移行
  • 外部統合/同期 (BizTalk/SSIS)
  • 他のアプリケーション (特に Web サイト、モバイル アプリケーションなど) による再利用
  • セキュリティ/攻撃面 (あるアプローチは別のアプローチよりも安全性が低いですか?)
  • メンテナンス作業
  • 可用性 - データベースは 24 時間年中無休で使用されますか? あるアプローチが別のアプローチよりも優れた可用性を提供するかどうかなど。

    • また、いくつかの設計上の考慮が必要です。より高速な選択またはより高速な書き込みをチューニングしていますか? あるデータ アクセス設計は、別の設計よりも優れたパフォーマンスを発揮する場合があります。

    特効薬が 1 つあると言っているわけではありませんが、注意すべきことは、データ アクセスの設計パターンには「全体像」を考える必要があるということです。つまり、今日の問題に対応できるか、明日のニーズを合理的に予測できるか、ということです。

    また、一貫したデータ アクセスのための外部 API または何らかのフレームワークを提供する予定はありますか? 直接または間接的に公開されますか?

    Entity Framework/LINQ to SQL、従来のストアド プロシージャ、および NHibernate などの他のツールの両方に場所があると思いますが、最初にテクノロジの選択を正当化および合理化し、それが適切であることを確認する必要があります。現在と将来のニーズ。

    EDIT：申し訳ありませんが、私は大きなものを忘れていました：保守性。テンプレート駆動型のソリューションの中には、スキーマの変更後に DAL を再生成できるという点で、他のソリューション (手書きのストアド プロシージャなど) よりも優れているものがあります。生産性の向上と不利な点を比較検討する価値があります。

    于 2008-10-14T13:33:02.380 に答える
    2

    ソフトウェア プロジェクトのすべての選択肢と同じように: それは場合によります... しかし、私の意見では、最も重要な要素はプロジェクトの環境です。

    これは次のもので構成されています (このリストが完全であるとは言いません):

    • 開発チームおよび保守チーム内で利用可能なスキル (異なる場合)
    • 必要な機能
    • クライアントによって設定された制約 (すべてのクライアントが利用可能なすべてのテクノロジをサポートしているわけではありません。これは、レガシー システムを段階的に置き換えたり、環境に新しいシステムを導入したりするときに考慮すべきことです)
    • 法律による制約

    これがお役に立てば幸いです。

    于 2008-10-14T13:44:14.120 に答える
    1

    元の投稿とnorbertBの追加の間で、ほぼすべてをカバーしたと思います。絶対的な制約から始めましょう（クライアントが何かに一度ノーと言ったからといって、たとえそれが絶対的だと言ったとしても、それは彼らの考えを変えるのを助けることができないという意味ではないということを覚えておいてください. ）. 絶対制約でフィールドを絞り込んだら、他のものを見てください。

    取り残されているように見えたものの1つは、柔軟性でした。たとえば、2 つの類似したテクノロジのどちらかを選択しようとしていて、一方が更新可能なビューをサポートし、もう一方がサポートできないことを知っていた場合、その時点で更新可能なビューがまったく必要なかったとしても、それでもその方に傾倒します」念のため"。

    于 2008-10-14T14:27:00.977 に答える
    0

    私は本当に2つのことしか考えていません。1 つ目は、他に重要なほど多くのデータを保持するかどうかです。何百万もの行をテーブルに入れていなければ、どのテクノロジを使用するかはおそらく問題ではありません。それらはすべて十分に高速に動作するからです。

    2 つ目は、LINQ を使用できるかどうかです。なぜなら、LINQ (to SQL、to Entities、to LLBLGen など) を使用してデータベースにクエリを実行すると、2 つの重要なことが得られるからです。1 つ目は、クエリの記述が非常に簡単であることです。2 つ目は、要件が変更された場合に、LINQ を必要とする 2 つのフレームワークを適度に簡単に切り替えることができることです。

    于 2008-10-14T13:39:37.343 に答える