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に変換することは有益でしょうか？

ASP.NET MVPパターンは、長期の ASP.NET Webフォームアプリケーションに最適なアーキテクチャです。それは、MV *パターンの背後にあるトレンドの事実上の事実である、「懸念の分離」の概念と関係し始めています。

上の質問なぜそれを使用するには？-この投稿で詳細に対処-ASP.NET MVP

• ASP.NET Webformsアプリケーションのテストの開始
• MVPとMVCのトレードオフ
• 混乱の終わり：MVPとMVC

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

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

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

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

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

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

編集する

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

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

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

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

Registration.RegisterUser（this）;

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

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

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

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