web-dev-qa-db-ja.com

コントローラ層での決定ステートメントの記述

MVCアーキテクチャに基づくRESTアプリケーションを開発しています。

サービスレイヤーはOptional<T>を返します。ここで、Tは任意のクラスです。

したがって、コントローラーレイヤーには、結果がOptional.emptyであるかどうかをテストし、データ[]を含むカスタム応答を返す条件ステートメントがあります。それ以外の場合は、カスタムResponseHTTP応答で実際のデータを返します。

return ABCService
    .getById("")
    .map("custom response with actual data ")
    .orElse(Collections.empty in Custom response)
    ;

このコードをコントローラーレイヤーに記述するのは悪い習慣ですか？

nullを送信したくないため、Optional<T>を返します。 Controllerレイヤーでその条件を使用しない場合は、サービスレイヤーから戻るOptionalも削除する必要がありますが、これは良い習慣ではないと思います。

上記のコードが適切でない理由を誰かが説明できますか？結果はどうなるでしょうか？

javarestmvcapi-designjava8
3
Mehraj Malik

それは本当にMVCをどのように行っているかに依存します。 [〜＃〜] mvc [〜＃〜] は、M、V、およびCの通信方法を指示しません。あなたがしているならあなたのコードは理にかなっています this ：

enter image description here

しかし、あなたがしている場合はそうではありません this ：

enter image description here

どちらを実行するかは、 コマンドクエリの責任の分離 についてどのように感じているかによって大きく異なります。

MVCを使用していると言っても、あまりわかりません。これは、さまざまな方法で再発明された古いデザインパターンです。この時点で一貫しているのは、3つの責任領域を分離するという考えだけです。

数十億ドルの間違いは、nullをタイピングシステムに入れることでした。 null許容型で生活していることを修正する言語を使用しない限り。

注意深くnullを返さないことは別のことです。 nullの意味はコンテキストごとに明確ではなく、通常は意図しない動作であるため、nullを返すことは避けてください。 nullオブジェクト を返すと、動作を制御し、意味を明確にすることができます。これは、Stringをnullではなく ""に設定するのと同じくらい簡単です。

Optionalは事実上コンテナであるため、nullを使用すると、Optionalオブジェクトクラスを定義しなくても同様の効果を得ることができます。ドットをオフにすると爆発するnullにさらされるのではなく、Optionalは何も含まないArrayListのように機能します。

Optionalは、nullの存在を停止しません。それは単にそれを処理することを抽象化します。 if (foo != null)チェックをOptionalに効果的に詰め込むので、それらを調べる必要はありません。また、Optionalを使い続ける限り機能します。 Optionalから抜け出し、そこにあるものに直接触れると、nullを処理して開始したところに戻ります。

返品でnullを忠実に回避することは魅力的に聞こえるかもしれませんが、何かがOptionalを返すと言っているからといって、それでもあなたを台無しにすることができず、時には裸のnullを返すことを意味しないことを理解してください。タイピングシステムはあなたにその約束をすることはできません。それは10億ドルの間違いです。

3
candied_orange