さまざまなデザインパターンが使用されていますが、明らかなものがいくつかあります。
プロキシ- [〜＃〜] aop [〜＃〜] および remoting で頻繁に使用されます。
シングルトン-spring configファイルで定義されたBeanは、デフォルトではシングルトンです。
テンプレートメソッド-定型的な繰り返しコード（接続をきれいに閉じるなど）を扱うために広く使用されます。たとえば、 JdbcTemplate 、 JmsTemplate 、 JpaTemplate 。
次のコメントを更新します。MVCの場合、 MVCリファレンス を読むことをお勧めします。
MVCで使用されるいくつかの明らかなパターン：
モデルビューコントローラー :-) Spring MVCの利点は、サーブレットではなくコントローラーがPOJOであることです。これにより、コントローラーのテストが容易になります。注意すべきことの1つは、コントローラーは論理ビュー名を返すためにのみ必要であり、ビューの選択は別の ViewResolver に任されているということです。これにより、さまざまなビューテクノロジーでコントローラーを再利用しやすくなります。
フロントコントローラー 。 Springは、 DispatcherServlet を提供して、着信要求がコントローラーに確実にディスパッチされるようにします。
View Helper -Springには、ビューでのプレゼンテーションからコードを分離するのを支援するために、多数のカスタムJSPタグと速度マクロがあります。
そしてもちろん、BeanFactory/ApplicationContext全体の中心である依存性注入、またはIoC（制御の反転）。
DIのことは、実際には何らかの戦略パターンです。何らかのロジック/実装を交換したい場合は通常、Hostクラスでインターフェイスと適切なセッターメソッドを見つけて、そのインターフェイスのカスタム実装を配線します。
SpringはベストプラクティスのAPIパターンのコレクションです。腕の限り、それらのショッピングリストを作成できます。 APIの設計方法は、これらのパターンに従うことを促します（ただし、強制するわけではありません）。
サービスロケーターパターン-ServiceLocatorFactoryBeanは、コンテキスト内のすべてのBeanの情報を保持します。クライアントコードが名前を使用してサービス（Bean）を要求すると、コンテキスト内でそのBeanを見つけて返します。クライアントコードは、Beanを見つけるためにスプリング関連のコードを記述する必要はありません。
Observer-Observable：ApplicationContextのイベントメカニズムで使用されます
Factoryメソッドpatter：オブジェクトのインスタンスを作成するBeanFactoryシングルトン：インスタンスタイプはコンテキストのシングルトンにすることができますプロトタイプ：インスタンスタイプはプロトタイプにすることができます。 Builderパターン：複雑なインスタンスの作成を担当するクラスでメソッドを定義することもできます。
ファクトリパターンは、BeanFactoryおよびアプリケーションコンテキストを介してBeanをロードするためにも使用されます。
Springコンテナは、Beanスコープ（シングルトン、プロトタイプなど）に応じてBeanオブジェクトを生成します。つまり、これは Abstract Factoryパターン を実装しているように見えます。 Springの内部実装では、各スコープは特定のファクトリの種類クラスに結び付けられるべきだと確信しています。