1

状況は次のとおりです。

  • ストアド プロシージャ (Oldschool) を呼び出す DAL を呼び出すメソッドを含むオブジェクト クラスを持つ BLL プロジェクトを使用する Asp.Net 3.5 Web サイトがあります。
  • 同じデータベースとオブジェクトを使用して、新しい Web サイト (Asp.Net 4 および MVC 3) を作成しています。また、既存のクラスとテーブルに関連する一連のクラスと新しいテーブル (おそらく 12 個) を追加します。

私の問題は：

これらすべてを連携させるにはどうすればよいでしょうか。私は本当に新しいプロジェクトに MVC を使用し、すべてをできる限り適切に機能させたいと考えています。古いプロジェクトは完全に混乱していますが、非常に巨大であるため、触れることはできません。

では、新しいオブジェクトをどのように処理するのでしょうか? classe とストアド プロシージャで同じ古いメソッドを使用しますか? 新しいオブジェクトとクラスのリポジトリ パターンを作成しますか? 等...

どうもありがとうございました

ps : 明確かどうかはわかりませんが、必要に応じて他の詳細をお知らせできます。

ps2 : コーディング ソリューションを探しているわけではありませんが、スムーズな統合のために従うべき最善の方法のいくつかの兆候

4

2 に答える 2

1

私は現在、正確な問題を抱えたプロジェクトで DataAccess レイヤーを仕上げています。これが私がそれを解決した方法です:

リポジトリ パターンを使用して、"新しいコード" が古いコードについて何も知らないようにしました。リポジトリでは、既存のロジックへの呼び出しを使用して「レガシー」エンティティを生成し、エンティティ フレームワークを使用して新しいエンティティを管理します。一部のエンティティでは、CRUD 操作に「組み合わせた」アプローチが必要です。たとえば、新しいユーザー エンティティを作成する場合、レガシー システムから 2 つの異なるオブジェクトを呼び出す必要があります。最初のエンティティは、別のレガシー オブジェクトを呼び出してユーザー インスタンスを作成し、ID を返すために使用する PIN を返します。その ID は最終的にオブジェクトの「newUser」部分を管理するために、新しい Entity フレームワークで使用されます。次に、このデータ アクセス レイヤーは、新しいシステムがエンティティを認識しているだけで、基になる従来の構造が何であるかを認識していない MVC プロジェクトに公開されます。そのため、MVC プロジェクト (およびこの場合はビジネス ロジック層も) はリポジトリのみを認識し、レガシー ロジック/CRUD 操作を新しいシステムに移動することを決定した場合、実際のリポジトリ以外は何も変更されません。これにより、場合によってはかなり「かさばる」リポジトリが作成されます (最も複雑なのは、ユーザーについて言及したものです) が、新しいコードとレガシー コードを明確に分離できます。

これがビジネス ロジックをデータ アクセス レイヤーに挿入していることはわかっていますが、私たちのプロジェクトでは、他の要因により、これは意図的な選択でした。必要に応じて、ビジネス ロジック レイヤーにレガシー レイヤーへの呼び出しを行わせることができます。

これが役に立てば幸いです。不明な場合はお知らせください。ここでは私の頭の中ほど明確ではない可能性があるため、さらに説明します:)

于 2012-09-06T12:57:57.277 に答える
0

MVC を使用するために、リポジトリ パターン、EF、または DI を使用する必要はありません。BLL を使用してビジネス オブジェクト (CRUD 操作) を取得する場合、それをコントローラーで直接使用できない理由はありません。

新しいクラス/テーブルを追加する限り、BLL がどの程度緊密に結合されているかによって異なります。インターフェイスを使用して疎結合されている場合は、一部の DAO に別のパターンを使用できるはずですが、DAO が相互に直接参照している場合は、それだけの価値があるよりも問題が発生する可能性があります。

さらに一歩進んで行きたい場合は、インターフェイスで CRUD 操作を定義し (まだインターフェイスがない場合)、BLL クラスにそれらを実装して、DI を使用して、次のようなときに痛みを軽減できるようにすることをお勧めします。別の DL 戦略に切り替えます。

于 2012-09-06T12:58:42.563 に答える