回答:
Model-View-View Model MVVMパターンの使用を検討してください。これはMVCの派生物ですが、説明した状況で使用するように設計/意図されています。あなたがそれをグーグルで動かしたくないと思うなら、MSDNサイトに豊富な情報があります。
MVVMは、グラフィカルユーザーインターフェイス（マークアップ言語またはGUIコード）の開発と、モデル（ビューと区別するためのデータモデル）と呼ばれるビジネスロジックまたはバックエンドロジックの開発との明確な分離を容易にします。モデル）。MVVMのビューモデルは値コンバーターです。つまり、ビューモデルは、モデルからのデータオブジェクトの管理と消費が容易になるように、モデルからデータオブジェクトを公開します。この点で、ビューモデルはビューよりもモデルであり、ビューの表示ロジックのすべてではないにしてもほとんどを処理します（ただし、どのレイヤーによってどの機能が処理されるかの境界は、継続的な議論と調査の対象です）。
短い答え：ビューとロジックを疎結合（デカップリング）することにより、潜在的なコードビハインドASP.NETフォームの問題を回避するMVPパターンを見てください。
MVC、MVP、ASP.NETなど、さらに一歩進んでこの比較を確認することもできます。
次の投稿は、適切なエントリポイントと例です。
しかし...あなたの述べた要件は非常に抽象的なものです：
抽象化を実現し、管理性と理解性を向上させる設計パターンを実装することにより、コードを改善したいと考えています。...
...そして、それらの目的のために、あなたはある種のレシピであるとして「デザインパターン」を探しているようです。 「抽象化」を要件として引用することもできます。
既存のアプリケーションで見つかった既存のコードは、通常、それを「改善」しようとしてもメリットがありません。「設計パターン」のような抽象化ではなく、現在の状態とまったく同じようにアプリケーション自体で、取り組みを完全に根拠づける必要があります。
私は何十年にもわたって、サービス中またはサービス中の50を超えるさまざまなアプリケーションを調べてきました。それぞれが「新しい」方法を課すことで、往年の「銀の弾丸」が見えてきました。実際には何も置き換えません。どちらの方法もまだ残っています。この「または銀の弾丸」がまったく試みられなかった場合、「管理性と理解性」は長期的には大幅に改善されたでしょう。
私の見解では、「デザインパターン」の全体的な概念は、それらが有用な会話を開始し、可能な代替案を提案する方法であるということです。しかし、それらはレシピではありません。
MVVMは、モデルバインディングとFormViewのようなテンプレート化されたバインドされたコントロールを使用して、NET 4.5で可能です。
これが私が使うテクニックです：
各UserControlとネストされたUserControlのViewModelを設計してから、常にEditModeにあるFormViewを使用します。ここでは、Binding式を使用してモデルプロパティにバインドするコントロールを含めています。
FormViewのSelectMethodとUpdateMethodを設定します。1つ目はViewModelを返し、2つ目はそれに対してTryUpdate（）を呼び出します。ポストバックでは、常にプリロードまたはロードでFormViewのUpdateメソッドを呼び出します。このようにして、ViewModelは常にビューから最新の状態になります。
ロジックをViewModel内で実行し、PreRenderでビューを再バインドして変更を適用します。このメソッドの重要な点は、ViewModelをビューの外（ページレベルなど）のビュー（UserControl）に挿入し、もちろん、これがシリアル化可能で、ViewStateまたは選択した他の場所にキャッシュされるようにすることです。
最後に、キャッシュされたステートフルViewModelによって常に「駆動」され、独自の状態を必要としないため、すべてのコントロールでViewStateを無効にします。
これまでのところ、この手法で失敗することはなく、WPFのように、コマンド/ボタンバインディングのソリューションも見つけられればいいのにと思います。