2

チーム A には、ストアド プロシージャを実行するデータ アクセスに ADO.NET を使用するエンタープライズ アプリがあります。データアクセスはそれ自身のプロジェクトにカプセル化されています (それを と呼びましょうDAL.dll)

チーム B は、エンタープライズ アプリでストアド プロシージャを再利用する別の無関係なアプリを作成しています。このアプリは現在、データ アクセスに MS アプリケーション ブロックを使用しています。私たちが遭遇する問題は、チーム A がストアド プロシージャの入力/出力パラメーターに変更を加えるたびに、チーム B のアプリで実行時エラーが発生し、追加のパラメーター (または変更されたパラメーター) に対応するためにこのアプリを更新する必要があるということです。削除されました）。そのため、これらのほとんどは、ユーザーが文句を言うまで気付かれません。少なくとも、アプリがコンパイル エラーをスローして、ビルド プロセスが変更を警告するようにしたいと考えています。

これを行う 1 つの方法は、チーム B のプロジェクトに参照を追加することです。DAL.dll

問題を解決するための他のよりクリーンな方法があるかどうか知りたいです。必要に応じて、チーム B の MS Data アプリケーション ブロックを別のテクノロジ (Entity Framework?) を使用するように置き換える準備ができています。

4

7 に答える 7

3

他の回答の中でも、これらのストアド プロシージャをDatabase Projectのソース管理に入れることを強くお勧めします。次に、ソース管理システムの機能を使用して、いくつかのことを実行できる場合があります。

  1. 一部のコードを変更できないようにロックする
  2. コードが変更された場合に通知する
  3. ストアド プロシージャが呼び出されないように変更された場合に警告する
  4. 変更されていないストアド プロシージャを共通に保ちながら、各チームが独自のバージョンの変更されたコードを持つことができるように、ストアド プロシージャを分岐します。もちろん、データベース内の異なるバージョンを分離する必要があります。
于 2013-07-02T17:05:28.930 に答える
1

DAL プロジェクトの所有者によっては、Web サービスをホストして API を共有できます。このようにして、データ アクセス レイヤーをビジネス ロジックから分離することで、同じ DAL を別の場所に公開しなくても、誰でも使用できるようになります。

私の見解では、チーム A とチーム B の両方が同じコア モデルを共有し、可能な解決策として多層アーキテクチャを検討する必要があるようです。

于 2013-07-08T19:38:00.687 に答える
1

エンタープライズ アプリでストアド プロシージャを再利用している無関係なアプリ

これらの 2 つのアプリケーションが実際には無関係である場合、なぜそれらは手順を共有したり、同じデータベースを共有したりするのでしょうか。これが長い読み物であることは承知していますが、これを読むことをお勧めします:エンタープライズ アーキテクチャへのより良い道

そこのパーティショニングの概念は、ドメイン駆動設計の境界付けられたコンテキストに関連しています。

大規模なプロジェクトでは、複数のモデルが使用されます。しかし、異なるモデルに基づくコードが組み合わされると、ソフトウェアはバグが多くなり、信頼性が低くなり、理解が困難になります。チームメンバー間のコミュニケーションが混乱します。多くの場合、どのような状況でモデルを適用してはならないかは明確ではありません。

したがって: モデルが適用されるコンテキストを明示的に定義します。チームの編成、アプリケーションの特定の部分での使用、およびコード ベースやデータベース スキーマなどの物理的な表現に関して、境界を明示的に設定します。これらの範囲内でモデルの一貫性を厳密に保ちますが、外部の問題に気を取られたり混乱したりしないでください。

これに明示的に対処しないと、問題が発生することが予想されます。長期的には問題を見つけるのがはるかに困難になる可能性があるため、初期の失敗が見られるのは幸運です。

上記を念頭に置いて、問題を再度分析してください。この共通機能が必要な明示的なコンテキストが欠落していないかどうかを検討してください。

于 2013-07-01T21:09:53.593 に答える
0

両方のアプリケーションが共有できる共有 DAL を作成するのは理にかなっているように思えます。

単体テスト (または実際には統合テスト) を追加して、変更後に DAL がアプリと互換性があることを確認します。そうすれば、互換性のない変更が行われた場合、テストは失敗します

于 2013-06-27T03:12:33.047 に答える
0

「この問題を解決するためのよりクリーンな方法が他にあるかどうか知りたいです。」

最もクリーンな方法は、チーム B がチーム A と話し合い、関連するビジネス ロジックを共有 API にカプセル化することです。その API をどのように実装するかはそれほど重要ではありません。重要なのは、API のインターフェースが文書化され、バージョン管理されているため、誰もが何を期待すべきかを知っているということです。

.NET 環境でこれを実現する合理的なメカニズムの 1 つは、Microsoft のWebAPIを使用することです。

要するに、「ストアド プロシージャをどのように共有するか」という問題です。間違ったレベルの抽象化を見ている可能性が最も高いです。

于 2013-07-08T15:12:45.847 に答える