Springの基本フレームワークの紹介と使用

モジュール性。

春の進化

単一のアプリケーションアーキテクチャ

ウェブサイトのトラフィックが非常に少ない場合、必要なアプリケーションは1つだけで、すべての機能が一緒にデプロイされ、デプロイノードとコストが削減されます。現時点では、追加、削除、変更、チェックの作業負荷を簡素化するために使用されるデータアクセスフレームワーク（ORM）が重要です。

垂直アプリケーションアーキテクチャ

訪問数が徐々に増えると、マシンに1つのアプリケーションを追加することによる加速はますます小さくなります。効率を向上させる方法の1つは、アプリケーションをいくつかの無関係なアプリケーションに分割して効率を向上させることです。現時点では、フロントエンドページの開発を加速するために使用されるWebフレームワーク（MVC）が重要です。

分散サービスアーキテクチャ

垂直アプリケーションが増えると、アプリケーション間の相互作用は避けられません。コアビジネスは独立したサービスとして抽出され、安定したサービスセンターが徐々に形成されるため、フロントエンドアプリケーションは変化する市場の需要により迅速に対応できます。現時点では、ビジネスの再利用と統合を改善するための分散サービスフレームワーク（RPC）が重要です。

モバイルコンピューティングアーキテクチャ

サービスが増えると、容量の評価や小さなサービスリソースの浪費が徐々に発生します。このとき、クラスターを改善するために、アクセスプレッシャーに基づいてクラスターの容量をリアルタイムで管理するディスパッチセンターを追加する必要があります。利用。現時点では、マシンの使用率を向上させるために使用されるリソーススケジューリングおよびガバナンスセンター（SOA）が重要です。

Javaの主流フレームワークの進化

1、JSP +サーブレット（サーバー+アプレット）+ JavaBean

jspはJavaコードに直接埋め込むことができます

2、MVC3層アーキテクチャ

DAO层：entity、bean、po、vo、bo、pojo

3.アプリケーション開発にEJBを使用しますが、EJBは重量のあるフレームワークであり（使用すると、インターフェイスと依存関係が多すぎて、非常に煩わしい）、使用するのが面倒です。

4、Struts1 / Struts2 + Hibernate + Spring

5、SpringMVC + Mybatis + Spring

6、SpringBoot開発、合意は構成よりも大きい

コア説明

Springはオープンソースフレームワークです。
Springは、企業の開発を簡素化し、開発をよりエレガントで簡潔にするために誕生しました。
SpringはIOCとAOPのコンテナフレームワークです。
IOC：制御の反転
AOP：アスペクト指向プログラミング
コンテナ：水のバケツを使用するのと同じように、アプリケーションオブジェクトのライフサイクルを格納および管理します。スプリングはバケツであり、オブジェクトは水です。

スプリングを使用する利点

1. Springは、DI、AOP、およびボイラープレートコードの排除を通じて、エンタープライズレベルのJava開発を簡素化します
2. Springフレームワークに加えて、コアフレームワーク上に構築された巨大なエコシステムがあり、SpringをWebサービス、REST、モバイル開発、NoSQLなどのさまざまな分野に拡張します。
3.侵入の少ない設計、コードの汚染が非常に少ない
4.さまざまなアプリケーションサーバーに依存せずに、Springフレームワークに基づくアプリケーションは、Write Once、RunAnywhereの約束を真に実現できます。
5. SpringのIoCコンテナは、ビジネスオブジェクトの置き換えの複雑さを軽減し、コンポーネント間の分離を改善します
6. SpringのAOPサポートにより、セキュリティ、トランザクション、ログなどの一般的なタスクを一元的に処理できるため、再利用が向上します。
7. SpringのORMとDAOは、サードパーティの永続性レイヤーフレームワークとの良好な統合を提供し、基盤となるデータベースアクセスを簡素化します
8. Springの高度なオープン性により、アプリケーションがSpringに完全に依存する必要はありません。開発者はSpringフレームワークの一部または全部を自由に選択できます。

3. IOC（制御の反転）：制御の反転

IOCを導入する理由

通常のJavaプロジェクトを作成して、次の機能を完了します

UserDao.java

package com.mashibing.dao;

public interface UserDao {
    public void getUser();
}

UserDaoImpl.java

package com.mashibing.dao.impl;

import com.mashibing.dao.UserDao;

public class UserDaoImpl  implements UserDao {
    @Override
    public void getUser() {
        System.out.println("获取用户数据");
    }
}

UserService.java

package com.mashibing.service;

public interface UserService {
    public void getUser();
}

UserServiceImpl.java

package com.mashibing.service.impl;

import com.mashibing.dao.UserDao;
import com.mashibing.dao.impl.UserDaoImpl;
import com.mashibing.dao.impl.UserDaoMysqlImpl;
import com.mashibing.service.UserService;

public class UserServiceImpl implements UserService {

    private UserDao userDao = new UserDaoImpl();

    @Override
    public void getUser() {
        userDao.getUser();
    }
}

SpringDemoTest.java

package com.mashibing.test;

import com.mashibing.service.UserService;
import com.mashibing.service.impl.UserServiceImpl;

public class SpringDemoTest {
    public static void main(String[] args) {
       UserService service = new UserServiceImpl();
       service.getUser();
    }
}

前のコード作成プロセスでは、すべてこの方法で関数を完了しましたが、UserDao実装クラスを追加するとどうなりますか？

UserDaoMysqlImpl.java

package com.mashibing.dao.impl;

import com.mashibing.dao.UserDao;

public class UserDaoMysqlImpl implements UserDao {
    @Override
    public void getUser() {
        System.out.println("mysql");
    }
}

mysqlを使用する場合は、UserServiceImpl.javaのコードを変更する必要があります。

package com.mashibing.service.impl;

import com.mashibing.dao.UserDao;
import com.mashibing.dao.impl.UserDaoImpl;
import com.mashibing.dao.impl.UserDaoMysqlImpl;
import com.mashibing.service.UserService;

public class UserServiceImpl implements UserService {

    private UserDao userDao = new UserDaoImpl();

    @Override
    public void getUser() {
        userDao.getUser();
    }
}

しかし、別のOracleクラスを追加するとどうなるでしょうか。

UserDaoOracleImpl.java

package com.mashibing.dao.impl;

import com.mashibing.dao.UserDao;

public class UserDaoOracleImpl implements UserDao {
    @Override
    public void getUser() {
        System.out.println("oracle");
    }
}

現時点では、UserServiceは引き続き変更する必要があります。明らかに、このメソッドはニーズに適していないため、解決方法として、次の方法を使用できます。

UserServiceImpl.java

package com.mashibing.service.impl;

import com.mashibing.dao.UserDao;
import com.mashibing.dao.impl.UserDaoImpl;
import com.mashibing.service.UserService;

public class UserServiceImpl implements UserService {
    private UserDao userDao;

    public void setUserDao(UserDao userDao){
        this.userDao = userDao;
    }
    @Override
    public void getUser() {
        userDao.getUser();
    }
}

テストクラスSpringDemoTest.java

package com.mashibing.test;

import com.mashibing.dao.impl.UserDaoMysqlImpl;
import com.mashibing.dao.impl.UserDaoOracleImpl;
import com.mashibing.service.UserService;
import com.mashibing.service.impl.UserServiceImpl;

public class SpringDemoTest {
    public static void main(String[] args) {
        UserServiceImpl userService = new UserServiceImpl();
        userService.setUserDao(new UserDaoMysqlImpl());
        userService.getUser();

        userService.setUserDao(new UserDaoOracleImpl());
        userService.getUser();
    }
}

実際、今のコードから、誰もがデカップリングの重要性を理解できるはずです。今度は、SpringのIOCの学習を開始します。

IOC初期

Iocは一種の考え方であり、DIは実装方法です（ IOCとDIは異なる観点から同じことを説明し、IOCはコンテナーの観点から説明し、DIはアプリケーションの観点から説明します）

IOCを理解したい場合は、次の質問を明確にする必要があります。

1.誰が誰を制御する
か
2.何を制御するか 3.逆転とは
4.どの側面が逆転するか

このプロセスを理解するのがより難しい場合は、ガールフレンドとマッチメイキング会社を見つけるプロセスを想像することができます。このプロセスを理解できれば、上記の質問に答えます。

1.誰が誰を制御するか：以前のコーディングプロセスでは、どのオブジェクト自体を作成するためにすべてのオブジェクトが必要であり、プログラマーがオブジェクト自体を制御しました。IOCコンテナーを使用すると、オブジェクトを制御するIOCコンテナーになります
。2。何制御の
反転：実装プロセスで必要なオブジェクトと依存する必要のあるオブジェクト。3。反転とは：IOCコンテナーがなくなる前に、オブジェクト内に依存オブジェクトをアクティブに作成しました。これは順方向回転であり、 IOCの後、依存オブジェクトはIOCコンテナによって直接作成され、アクティブな作成からパッシブな受け入れまで、オブジェクトに注入されます。これは反転
4です。どの側面が反転されますか：依存オブジェクト

基本コンセプト

IoCは、依存性注入（DI）とも呼ばれます。これは、コンストラクター引数、ファクトリメソッドへの引数、またはファクトリメソッドから構築または返された後にオブジェクトインスタンスに設定されるプロパティを介してのみ、オブジェクトが依存関係（つまり、オブジェクトが処理する他のオブジェクト）を定義するプロセスです。。コンテナは、Beanを作成するときに、これらの依存関係を注入します。このプロセスは基本的に、クラスの直接構築またはService Locatorパターンなどのメカニズムを使用して、依存関係のインスタンス化または場所を制御するBean自体の逆（したがって、名前、制御の反転）です。
IOCは、よく知られている依存性注入に似ています。これは、依存性を介してオブジェクトを注入するプロセスです。つまり、オブジェクトが使用するオブジェクトは、コンストラクターパラメーター、ファクトリメソッドパラメーター、またはファクトリメソッドコンストラクターまたはプロパティセットからのものです。戻り値のオブジェクトインスタンスによって、次にコンテナはBeanの作成時にこれらの必要な依存関係を注入します。このプロセスは、オブジェクトを作成する通常のプロセス（IoCという名前）とは逆になります。Bean自体は、クラスを直接構築することによって依存関係のインスタンス化または場所を制御するか、サービスロケーターパターンなどのメカニズムを提供します。

IN与IOC

IOCとDIは同じものだとよく言われますが、一般的には問題ありませんが、本質的には違いがあります。もっと厳密に言っていただければと思います。IOCとDIは同じことを違う角度から表現しています。IOCです。コンテナの観点から説明し、DIはアプリケーションの観点から説明します。IOCは設計アイデアであり、DIは特定の実装であるとも言えます。

4.まとめ

ここでの要約では、2つのことを理解できることを願っています：

1、デカップリング

オブジェクト指向設計ソフトウェアシステムでは、基盤となる実装はN個のオブジェクトで構成され、すべてのオブジェクトが相互に連携して、システムのビジネスロジックを最終的に実現します。

このような組み合わせ関係では、特定のオブジェクトに問題が発生すると、他のオブジェクトに影響を与える必要があることに注意してください。これは、結合が高すぎるためですが、オブジェクトの結合関係は避けられません。必要です。アプリケーションがますます大きくなるにつれて、オブジェクトの結合はますます複雑になり、複数の依存関係が必要になることがよくあります。したがって、アーキテクトとプログラマーの両方が、このようなシナリオに直面したときにこれらのオブジェクトの結合を減らす必要があります。

結合関係は、オブジェクトとオブジェクトの間だけでなく、ソフトウェアシステムのさまざまなモジュールの間にもあります。これは、私たちが焦点を当てる必要のある問題です。オブジェクト間の過度の結合の問題を解決するために、IOCを介してオブジェクト間の分離を実現できます。SpringFrameworkは、IOC理論の最も広く使用されているアプリケーションです。

上の図からわかるように、サードパーティのコンテナが導入された場合、複数のオブジェクト間に結合関係はありません。すべてのオブジェクトはコンテナによって制御されます。このコンテナは接着剤に相当し、オブジェクトは接着されます。役割を果たすために。

2、生態学的

言語やフレームワークが無敵になりたい場合、最も重要なことはそのエコロジーです。