コーディングスタイル：MvcモードのSSM環境、コードレイヤード管理

この記事のソースコード：GitHub・ここをクリック|| GitEE・ここをクリック

1.層別化戦略

MVCパターンとコードの階層化戦略MVCのフルネームはModel-View-ControllerであるModelViewControllerです。ソフトウェア設計のモデルとして、ビジネスロジック、データ、およびインターフェイス表示を分離する方法でコードを編成し、ビジネスロジックを1つにまとめます。コンポーネントでは、インターフェイスとユーザーインタラクションを改善およびカスタマイズする際に、ビジネスロジックを書き直す必要はありません。これは開発モードですが、実際の開発ではコードの階層モードではありません。通常、SSMフレームワークのバックエンドコードは次のように分割されます。レイヤーは次のとおりです。

• コントローラ制御層：サーバーインターフェイス、入力および出力パラメータを定義し、いくつかの入力パラメータを確認します。
• サービスビジネスサービスレイヤー：ビジネスロジックの組み立て、ビジネス検証、および制御レイヤーに必要なパラメーターモデルの構築。
• daoデータインタラクションレイヤー：サービスレイヤーに必要なデータクエリメソッドと、データインタラクション条件に関連するプロセスロジックを提供します。
• マッパー永続性レイヤー：非常に一般的に使用される永続性レイヤーコンポーネントであるmybatisフレームワークに必要なネイティブサポートに基づいています。

第二に、制御層

1.レストインターフェーススタイル

リソースへのアクセスと処理のロジックに基づいて、さまざまなスタイルの注釈が使用されます。たとえば、リソースの追加、更新、クエリ、削除。

/**
 * 新增
 */
@PostMapping("/insert")
public Integer insert (@RequestBody BaseInfo baseInfo){
    return baseInfoService.insert(baseInfo);
}
/**
 * 更新
 */
@PutMapping("/update/{id}")
public String update(@PathVariable(value = "id") Integer id,
                     @RequestBody BaseInfo baseInfo) {
    if (id<1){
        return "error";
    }
    baseInfo.setId(id);
    return "update="+baseInfoService.update(baseInfo);
}
/**
 * 主键查询
 */
@GetMapping("/detail/{id}")
public InfoModel detail(@PathVariable(value = "id") Integer id) {
    return baseInfoService.detail(id) ;
}
/**
 * 主键删除
 */
@DeleteMapping("/delete/{id}")
public String delete(@PathVariable(value = "id") Integer id) {
    baseInfoService.delete(id) ;
    return "SUS" ;
}

2.インターフェースの再利用

インターフェイスを頻繁に再利用することはお勧めしません。たとえば、各インターフェイスの追加、削除、変更、チェックで十分です。基本的な原則は、さまざまなクライアント操作がインターフェイスから独立していることです。

/**
 * 列表加载
 */
@GetMapping("/list")
public List<BaseInfo> list() {
    return baseInfoService.list(new BaseInfoExample()) ;
}
/**
 * 列表搜索
 */
@PostMapping("/search")
public List<BaseInfo> search (@RequestParam("userName") String userName,
                              @RequestParam("phone") String phone) {
    return baseInfoService.search(userName,phone) ;
}

たとえば、一般的なリストインターフェイスであるリストには、通常、条件に応じて読み込まれる検索メカニズムがあり、検索の判断条件は非常に複雑です。2つのインターフェイスに分割することをお勧めします。実際的な考慮事項から、ほとんどのシナリオではリストインターフェイスのみを使用し、まれにしか使用しません。検索を使用して検索します。

3.出入り

特定の条件を入力する必要があるなど、クライアントの必要な条件を確認します。問題がある場合は、要求リンクをすばやくブロックして、プログラムエントリ制御層がリターンをインターセプトするようにします。

@PutMapping("/update/{id}")
public String update(@PathVariable(value = "id") Integer id,
                     @RequestBody BaseInfo baseInfo) {
    if (id<1){
        return "error";
    }
    baseInfo.setId(id);
    return "update="+baseInfoService.update(baseInfo);
}

パラメータが3未満の場合は、直接表示できます。パラメータが3以上の場合は、エンティティクラスを使用してカプセル化できます。

@PostMapping("/search")
public List<BaseInfo> search (@RequestParam("userName") String userName,
                              @RequestParam("phone") String phone) {
    return baseInfoService.search(userName,phone) ;
}

4.パラメータ処理

パラメータ形式の処理度の基本原則は、サーバーが不要な操作を回避するためのパブリックリソースであるということです。たとえば、クライアントは、戻り値が空かnullかなどを判断したり、いくつかの一般的な形式を処理したり、クライアントを使用してサーバーの圧力を適切に共有したりできます。

3、ビジネスサービスレイヤー

1.ビジネス検証

たとえば、着信注文番号はデータベースレイヤーによって照会され、注文データはありません。これはビジネスの性質の例外と呼ばれます。コード自体には問題はありませんが、ビジネスロジックは正常に実行できません。

public InfoModel detail(Integer id){
    BaseInfo baseInfo = baseInfoDao.selectByPrimaryKey(id) ;
    if (baseInfo != null){
        DetailInfoEntity detailInfoEntity = detailInfoDao.getById(id);
        if (detailInfoEntity == null){
            LOG.info("id="+id+"数据缺失 DetailInfo");
        }
        return buildModel(baseInfo,detailInfoEntity) ;
    }
    LOG.info("id="+id+"数据完全缺失");
    return null ;
}

2.ビジネスロジックを組み立てます

通常、サービスレイヤーは複雑なロジックであり、ビジネスのコアステップをつなぎ合わせるために使用されます。プログラムは、ビジネスロジックの判断を通じて段階的に実行できるため、プログラムエントリでの多数のオブジェクト作成やデマンドデータクエリを回避できます。

public int insert (BaseInfo record){
    record.setCreateTime(new Date());
    int insertFlag = baseInfoDao.insert(record);
    if (insertFlag > 0){
        DetailInfoEntity detailInfoEntity = new DetailInfoEntity();
        detailInfoEntity.setUserId(record.getId());
        detailInfoEntity.setCreateTime(record.getCreateTime());
        if(detailInfoDao.save(detailInfoEntity)){
            return insertFlag ;
        }
    }
    return insertFlag;
}

3.データモデルの構築

通常、ビジネスレイヤーは少し複雑です。ビジネスレイヤーをすばやく理解したい場合は、複雑なビジネスメソッドに戻って、サービスレイヤーがコントロールレイヤーに返す必要のあるパラメーターを処理する方法を提供できます。ヘビーサービスレイヤー方式がより明確になります。

private InfoModel buildModel (BaseInfo baseInfo,DetailInfoEntity detailInfo){
    InfoModel infoModel = new InfoModel() ;
    infoModel.setBaseInfo(baseInfo);
    infoModel.setDetailInfoEntity(detailInfo);
    return infoModel ;
}

第四に、データ相互作用層

1.リバースエンジニアリング

ここでは、mybatisフレームワークまたはmybatis-plusフレームワークを参照として使用します。mybatisフレームワークの場合は、リバースエンジニアリングのテンプレートコードをカスタマイズしないことをお勧めします。メソッドをカスタマイズする必要がある場合は、テーブルを回避するために、マッパーおよびxmlレベルで拡張ファイルをカスタマイズして、カスタマイズしたメソッドとSQLロジックを保存します。大きな構造変化によって引き起こされる強い不快感。

もちろん、それらのほとんどは現在、永続化レイヤーコンポーネントとしてmybatis-plusを使用しており、上記の問題を回避できます。

2.データの相互作用

ビジネスレイヤーのニーズに応じて、対応するデータクエリメソッドを提供し、データベースとの対話のロジックのみを処理し、ビジネスロジックを回避します。特に分散アーキテクチャでは、データクエリとさまざまなサービスのアセンブリをこのレイヤーに表示しないでください。

public interface BaseInfoDao {

    int insert(BaseInfo record);

    List<BaseInfo> selectByExample(BaseInfoExample example);

    int updateByPrimaryKey(BaseInfo record);

    BaseInfo selectByPrimaryKey(Integer id);

    int deleteByPrimaryKey(Integer id);

    BaseInfo getById (Integer id) ;
}

5、ソースコードアドレス

GitHub·地址
https://github.com/cicadasmile/data-manage-parent
GitEE·地址
https://gitee.com/cicadasmile/data-manage-parent

推奨読書：仕上げプログラミングシステム

シリアルナンバー	プロジェクト名	GitHubアドレス	GitEEアドレス	推奨
01	Javaは、設計パターン、アルゴリズム、およびデータ構造を記述します	GitHub・ここをクリック	GitEE・ここをクリック	☆☆☆☆☆
02	Javaの基盤、並行性、オブジェクト指向、Web開発	GitHub・ここをクリック	GitEE・ここをクリック	☆☆☆☆
03	SpringCloudマイクロサービスの基本コンポーネントケースの詳細な説明	GitHub・ここをクリック	GitEE・ここをクリック	☆☆☆
04	SpringCloudマイクロサービスアーキテクチャの実際の戦闘の包括的なケース	GitHub・ここをクリック	GitEE・ここをクリック	☆☆☆☆☆
05	SpringBootフレームワークの基本的なアプリケーションから高度なものまで	GitHub・ここをクリック	GitEE・ここをクリック	☆☆☆☆
06	SpringBootフレームワークは、一般的なミドルウェアを統合および開発します	GitHub・ここをクリック	GitEE・ここをクリック	☆☆☆☆☆
07	データ管理、配布、アーキテクチャ設計の基本的なケース	GitHub・ここをクリック	GitEE・ここをクリック	☆☆☆☆☆
08	ビッグデータシリーズ、ストレージ、コンポーネント、コンピューティング、その他のフレームワーク	GitHub・ここをクリック	GitEE・ここをクリック	☆☆☆☆☆