0

私は次のプロジェクトで解決策を持っています：

ソリューション-Website1プロジェクト（Asp.Net MVC、コードファーストマイグレーションを使用したazure Webサイトプロジェクト）-BLLプロジェクト（クラスライブラリ）-DALプロジェクト（クラスライブラリ）-Website2プロジェクト（Asp.Net MVC、azure webroleプロジェクト）-Website2.Azureプロジェクト（Website2のクラウドプロジェクト）

Webサイト1とWebサイト2はどちらも、ビジネスロジックとデータアクセスにBLLプロジェクトとDALプロジェクトを使用しています。DALモデルをDALクラスライブラリに変更し、Website1プロジェクトでコードの最初の移行を実行すると、開発データベースのデータベース構造が変更されます。

また、website1プロジェクトをAzure Webサイトに公開すると、本番データベースの構造が自動的に更新され、Website1は本番環境で正常に機能しますが、Website2の本番コードは更新されたデータベースに古いBLLとDALを使用しているため、Website2の本番コードは機能しなくなります。構造..

だから私の質問は：これを最善の方法で管理するにはどうすればよいですか？

  1. 2つのWebサイト/MVCプロジェクトを同時にAzureにスマートにデプロイできますか？継続的な展開、TFSPreviewなどを使用します。（1つは紺碧のWebサイトに公開し、もう1つは紺碧のWebロールに公開します）
  2. db構造が変更されたかどうかは問題ではないことをwebsite2に伝える方法はありますか？とにかく続行します（もちろん、プロパティを使用しようとしたときにプロパティが欠落しているとエラーが発生しますが、残りは更新されるまで機能し続ける可能性があります/ウェブサイトの公開2）。
  3. 他のアイデア...

前もって感謝します！

4

1 に答える 1

0

こんにちは、私の回答は「その他のアイデア」のカテゴリに分類されます..

BAL が DAL に依存している場合、特定の種類の変更が BAL に影響します。たとえば、テーブル A、B、および C があるスキーマがあるとします。これらのテーブルすべてをビジネス エンティティとして DAL で公開し、BAL はそれらを操作する操作を公開しています。

ここで、テーブル C を削除して DAL を再生成すると、DAL で C を見つけることができなくなるため、BAL が壊れます。

ただし、新しいエンティティ E を追加して DAL を再生成すると、BAL は操作に E を使用しないため、影響を受けません。

この種の強い結合を最小限に抑えるためにできることの 1 つは、Data Transfer Object パターンを導入することです。DTO パターンを使用すると、DAL エンティティを完全に個別のクラスにパッケージ化し、そのクラスを使用して外部ドメインと通信します。

DAL が変更された場合、これらの変更を残りの呼び出しコード (この場合は BAL) に伝達する方法は DAL 次第です。DAL が C を削除した場合でも、C を表す DTO を保持し、上位層のコードから要求されたときに特定のアクションを実行できます (C のリストを要求されたときに null を渡すなど)。

通常、DTO パターンは UI と BAL の間の通信に使用されますが、DAL から BAL への通信にも使用できます。

これの欠点の 1 つは、コードに別の複雑なレイヤーが追加されることです。したがって、この前に他の潜在的な解決策を考えて排除する必要があります。

このソリューションは Azure に固有のものではありませんが、任意の n 層ソリューションで使用できる非常に一般的なソリューションです。

ハッピーコーディング

于 2013-02-07T03:23:25.040 に答える