web-dev-qa-db-ja.com

ASP.NET WebFormsアプリケーションに最適なアーキテクチャ

クライアント用のASP.NET WebFormsポータルを作成しました。プロジェクトは、最初から適切に計画および構造化されているのではなく、ある程度進化しています。その結果、すべてのコードは同じプロジェクト内でレイヤーなしでマッシュされます。クライアントは機能に満足しているので、プロジェクトのリリースに自信を持つようにコードをリファクタリングしたいと思います。アーキテクチャの設計にはさまざまな方法があるようですが、最善の方法についていくつかの意見をお願いします。

[〜＃〜]機能[〜＃〜]

ポータルでは、管理者がHTMLテンプレートを構成できます。他の関連する「パートナー」は、自分のサイトにIFrameコードを追加することにより、これらのテンプレートを表示できます。これらのテンプレート内で、顧客は製品を登録および購入できます。 APIはWCFを使用して実装されており、外部の企業もシステムとインターフェイスできます。管理者セクションでは、管理者がさまざまな機能を設定し、各パートナーのレポートを表示できます。システムは請求書と電子メール通知を顧客に送信します。

現在のアーキテクチャ

現在、データベースへの読み取り/書き込みにEF4を使用しています。 EFオブジェクトは、aspxファイル内で直接使用されます。これにより、サイトを作成している間、迅速な開発が容易になりましたが、dbとUIを密に結合しているため、このように維持することはおそらく受け入れられません。特定のビジネスロジックがEFオブジェクトの部分クラスに追加されました。

[〜＃〜]質問[〜＃〜]

リファクタリングの目標は、サイトをスケーラブルで、簡単に保守でき、安全にすることです。

  1. これにはどのようなアーキテクチャが最適ですか？各レイヤーに何があるべきか、DTO/POCO /アクティブレコードパターンを使用する必要があるかどうかなどを説明してください。

  2. DTO/BOを自動生成するための堅牢な方法はありますか？追加のレイヤーがあっても、将来の拡張は簡単に実装できますか？

  3. プロジェクトをWebFormsからMVCに変換することは有益でしょうか？

c#architectureasp.netmvcwebforms
10
stack man

ASP.NET MVPパターンは、長期ASPに最適なアーキテクチャです.NET webformsアプリケーション。これは、MV *パターンの背後にあるトレンドである「懸念の分離」の概念と連動しています。

Whyを使用する理由は？ -この投稿の詳細で対処- ASP.NET MVP

5
Yusubov
  1. 個別のロジックとUIにMVPパターンを使用するため、将来的には既存のロジックを再利用して別のUIテクノロジーに移行できます
  2. ビジネスロジックを再利用する任意のRDBSに変更できるように、BLとDALの間でリポジトリパターンを使用します
  3. bOとDALに別々のレイヤー（Dll）を用意して、メンテナンスを最小限に抑えます。
1
Arunachalam

ElYusubovが述べたように、MVPパターンは素晴らしいものになる可能性があります。

重要な概念は、コードビハインドからロジックのほとんどまたはすべてを取り除くことです。ロジックはページにバインドされるべきではありません。あるページのロジックを別のページで再利用する必要がある場合はどうなりますか？あなたはコピー＆ペーストしたくなるでしょう。これを行っている場合、プロジェクトは保守可能になります。

そのため、まず、コードビハインドからロジックをリファクタリングし、ビジネスレイヤーに配置します。分離コードからすべてのロジックを取得できた場合は、必要なインターフェースを実装して真のMVPにすることができます。

また、データアクセスがビジネスロジックから分離されていることを確認してください。データレイヤーを作成し、その端でもリファクタリングを開始します。 EF4を使用しているので、EFは既にこのエンドを分離しているはずなので、これはそれほど問題ではありません。すべてのEFファイルを別のプロジェクトに簡単に移動し、それを必要とするプロジェクトへの参照を追加するだけで済みます。さらに、他のプロジェクトでデータモデルを参照する必要がある場合もあります。

圧倒されないように、少しずつリファクタリングしてください。コードに触れたときは常に、その周りのコードをリファクタリングすることを検討してください。これを行うと、時間の経過とともにプロジェクトの保守性が向上します。

編集する

背後のコードにビジネスロジッククラスを継承させることについて質問しました。 「is-a」ページの背後にあるコードのため、これは実行できません。 C＃では多重継承が許可されていないため、分離コードクラスをページとカスタムオブジェクトの両方にすることはできません。概念的にロジックを分離する必要があります。おそらく、コードビハインドのコードがさまざまなことをしている場合です。クラスは1つのことだけを行う必要があります。既存の機能を概念的に引き出す方法について考えてみてください。たとえば、登録ページがあり、ユーザー情報を収集しているとします。おそらく、登録というボタンと、そのボタンに関連付けられたクリックイベントがあります。その場合、ユーザー情報を保存し、必要な処理をすべて実行します。そのすべてのロジックを処理するためのRegistrationオブジェクトを作成できます。分離コードでは、自分でロジックを実行する代わりに、情報をRegistrationオブジェクトに渡すことができます。

これはより明確な分離であるだけでなく、コードを自己文書化する方法にもなります。誰かがあなたのコードを読むとき、彼らはあなたがRegistrationオブジェクトを呼んでいるのを見るので、あなたは何が起こっているのか正確に知ることができます。

MVPパターンに厳密に従う場合は、パラメーターをRegistrationオブジェクトに渡す代わりに、分離コードがインターフェイスを実装します。インターフェースの実装は、基本的にすべてのビューオブジェクト（テキストフィールドなど）をインターフェースにマップします。例えば公開文字列FirstName {get {return txtFirstName.Text; }}

それが完了したら、ページをRegisrationオブジェクトに渡すことができます

Registration.RegisterUser（this）;

そして、このRegisterUserメソッドはインターフェースをパラメーターとして受け取ります

public bool RegisterUser（IUser user）{user.FirstName ...}

パブリックインターフェイスIUser {パブリック文字列FirstName; }

このMVPが混乱しているように思える場合は、リファクタリングに集中して、コードの再利用を最大化することがすべてのポイントであると理解してください。自分を繰り返すことは、もはやありません。それが DRYプリンシパル です。

0
coder