0

現在の開発モデルでは、通常、次のソリューション構造を使用しています。

  D     
  a 
  t ---- Presentation (MVC, WCF, WPF)
  a            |
    --- Business Logic
  M            |            
  o ----- Data Access (Repositories & Unit of Work)
  d            |
  e ------- Entities (EF or nHibernate)
  l
  s

EF がリポジトリと UOW であるという議論があることは知っていますが、それらをビジネス ロジックから除外することは依然として有利であることがわかりました。

開発の取り組みを、Azure の使用にもっと集中するように移行し始めています。Azure を使用するために、いくつかの Web アプリをリファクタリングします。

ソリューションの構築方法を再考するやむを得ない理由があるかどうか疑問に思いました。

4

1 に答える 1

1

アプリケーションを Azure に移植する際に留意すべきいくつかの提案を次に示します。

  1. アプリケーションを Azure に移植する理由は何ですか? 本当にスケーラビリティを目指しているのであれば、疎結合の分散アプリケーションが本当に必要になるかもしれません。現在のアーキテクチャが本当に分散アプリケーションの 1 つであるかどうかは明らかではありません。たとえば、すべてのレイヤーを 1 台のマシンでホストする必要があるか、または複数の処理ユニットに分散できるように疎結合する必要があるかなどです。Azure の場合、少なくとも分散環境を認識できるようにアーキテクチャを調整する必要があります。たとえば、タイムアウトや単一レイヤー間の接続/メッセージの損失を処理します。はい、すべてのレイヤー間で堅牢な通信が必要な場合は、明示的に何かを行う必要があります (キューまたはサービス バスでメッセージを使用する)等。）

  2. セキュリティはどうですか？ユーザー (存在する場合) は、アプリケーションで自分自身をどのように認証しますか? Azure AD Servicesを使用したり、仮想マシンで独自の AD コントローラーを実行したり、オンプレミスの AD コントローラーをインスタンスで使用できるようにしたりすることが必要になる場合があります (これはややこしいことかもしれません)。

  3. 使用している究極のデータ ストレージは何ですか? このストレージのタイプ (リレーショナル データベース、非リレーショナル データベースなど) に応じて、SQL Azure をデータの RDBMS として使用するか、クラウドでMongoDB を実行するか、テーブルと BLOB ストレージを使用することができます。繰り返しますが、これを念頭に置く必要があります (たとえば、EF の再試行ポリシーとタイムアウト ポリシーを構成します)。

  4. ホスティング モデルと仮想化のレベルは? 必要な仮想化のレベル (Iaas から PaaS まで) によっては、任意の時点でアプリケーションがシャットダウンされ、すべてのローカル ドライブ ストレージが完全にリセットされて再生成される可能性があることに注意する必要があります。したがって、(一時的に) ローカルに保存されたデータに依存している場合は、ストレージ メカニズムを Azure が提供するもの (BLOB やテーブル ストレージなど) に変更することをお勧めします。

于 2013-05-20T20:29:47.797 に答える