0

オブジェクト指向言語が再利用機能を提供することは誰もが知っていることです。

シンプルな 3 層アプリケーションがあります。

  1. プレゼンテーション層
  2. ビジネス層は、再利用性の利点を享受するように設計されています
  3. datalayer はばかげた ado.net ライブラリです (ばかげたというのは、ビジネス ロジックが実装されていないことを意味します)。

このデータレイヤーでコードの再利用性を強化するのに苦労しています。データレイヤーのメソッドの 1 つに疑似パターンを貼り付けています。

create connection object
open connection to database
create a transaction object
begin transaction
create command object
execute it
.
.
.
.
create nth command object
execute it
commit transaction
close connection

実際には、このコードは約 300 ～ 400 行のコードに膨れ上がり、このコードを読み取ることができなくなります。

この一連のコマンド実行では、さまざまなテーブルでクエリを選択/挿入/更新しています。トランザクション中でなければ、このコードをそれぞれのクラスに分けていただろう。

私が最近遭遇したスパゲッティ パターンが再びあります。

business layer method1 calls datalayer method to update column1 
business layer method2 calls datalayer method to update column2
businees layer method3 calls datalayer method to save the entire result in table by updating it.

このパターンは、再利用性のメリットを享受しようとしたときに発生しました。これらのメソッドは別の場所から呼び出されるため、再利用されました。ただし、再利用性を考慮せずに単純な sql クエリを作成すると、データベースへの呼び出しが 1 回だけになります。

では、データ層で再利用性を実現できるパターンや手法はありますか?

ノート：

  1. プリコンパイルの利点などを提供するという事実にもかかわらず、ストアドプロシージャを使用したくありません。特定のデータベースにより固有のデータレイヤーを結び付ける傾向があるためです。
  2. また、現在、プレーンな ADO.net のみで ORM ソリューションを検討していません。

ORM を考慮しない言い訳。

  1. 学習曲線
  2. データレイヤー自体のORMコードを制限することで削除できると思われる特定のORMへの密結合を回避します。
  3. 6 か月前にインターネットをチェックしたところ、その時点で利用可能な、人気のある、または広く使用されている ORM ソリューションは 2 つしかありませんでした。Entity Framework と NHibernate。学習を開始するためにEntity Framework を選択しました (何らかの理由で後で link1、link2にリンクしますが、Microsoft が提供しているため、EF を使用するのは簡単だと感じました)。
  4. 私がこの本で使用したこのMicrosoft 推奨の本には、 TPT、 TPH、および TPCの 3 つの手法がありました 。試したことのないTPC。
  5. Entity Framework から生成された SQL を確認したところ、非常に見苦しく、余分な列が作成されていました。ID、いくつかの見苦しい Case ステートメントなどです。高度にトランザクションの多いシステムでは、ORM ソリューションを適用できないようです。つまり、毎分 1000 回の挿入が行われているということです。データベースのサイズは拡大し続けており、遠い将来には 500 ～ 600 GB 近くに達するでしょう。
4

2 に答える 2

2

あなたの質問へのコメントに同意します。可能であれば、ここで車輪の再発明を避け、ORM を使用する必要があります。経験から言えば、コードを書いてずっと前に解決された問題を解決することになり、長い目で見ればおそらくもっと時間がかかるでしょう。ただし、ORM の使用を許可しない制約がある場合があることは理解しています。

私が参考になったいくつかの記事を次に示します。

この最初の記事は古いものですが、データ アクセスの設計パターンに使用できるさまざまなオプションについて説明しています。これにはいくつかの異なるパターンがあり、どれが最適かを実際に判断できるのはあなただけですが、リポジトリ パターンを確認することをお勧めします。

http://msdn.microsoft.com/en-us/magazine/dd569757.aspx

この次の記事は、データ マッパーを使用してリポジトリ パターンを実装する方法について説明するシリーズの第 1 回です。これは、上記の例に基づいて、おそらく冗長なコードの一部を削減するのに役立ちます。

http://blogsprajeesh.blogspot.com/2010/02/data-access-layer-in-c-using-repository.html

最後に、データ アクセス パターンの実装方法によっては、テンプレート パターンとジェネリックが役立つ場合があります。次の記事ではそれについて少し説明しており、そこからいくつかの役立つ情報を収集できます。

http://www.c-sharpcorner.com/UploadFile/rmcochran/elegant_dal05212006130957PM/elegant_dal.aspx

プロジェクトについて詳しく知らなければ、どのパターンがニーズに最も適しているかを正確に判断することは困難です。ただし、Unit of Work パターンとリポジトリおよびデータ マッパーを組み合わせて使用​​すると、一部のコードを再利用してデータ アクセスを管理するのに役立つ可能性があります。

于 2013-08-27T19:29:23.877 に答える
0

私が見ていないのはあなたのモデルレイヤーです。

ビジネス層と DAO 層がありますが、モデルはありません。 

business layer method1 calls datalayer method to update column1 
business layer method2 calls datalayer method to update column2
businees layer method3 calls datalayer method to save the entire result in table by updating it.

なぜこれではないのですか：

business layer updates model/domain object A
business layer updates model/domain object A in a different way
business layer persists model/domain to database through data layer.

このようにして再利用し、データベースへのループの繰り返しを回避します。

最終的には、ビジネス層がデータベースのデータ モデルをあまりにも多く知っているように思えます。ビジネス メソッドだけでなく、ビジネスオブジェクトが必要です。

于 2013-08-28T14:50:07.783 に答える