0

Grails フレームワークでは、コマンド オブジェクト パターンを見ましたが、その使用方法はあまり明確ではありません。さらに、Grails のドキュメントに記載されている例のほとんどは、コマンド オブジェクトではなくドメイン クラスに関するものです (コード例を簡略化するためかもしれません)。

1 - コマンド オブジェクトは、ビューとコントローラー レイヤーの間で使用されるものであり、そこにとどまる必要がありますか?

2 - または、コマンド オブジェクトをサービス レイヤーに渡すことをお勧めしますか?

ポイント 2 を説明するには:

class MyController {

    def updateUserPassword (UserPasswordCommand cmd) {
        ...
        myService.updatePassword(cmd)
        ...
    }
}

ポイント 2 が悪い習慣である場合、送信されたデータをサービス層に渡すにはどうすればよいでしょうか? ドメインクラス経由？ 編集：問題ないようです

[編集]

ドメインクラスではなくコマンドオブジェクトを使用する場合、この場合の対処方法:

def signup(UserCreateCommand cmd)
{
    if (!cmd.hasErrors()) {
            def userInstance = userService.signup(cmd)
        }
    }
    if (cmd.hasErrors()) {
        /* Stay on form in order to display errors */
        render(view:"/app/authentication/_signupForm", model:[userCreateCommand: cmd])
        return
    }
    ...
}

ユーザー サービス トランザクションが終了したときに、データベースによって例外が発生した場合 (スキーマの制約を無視してデータをフラッシュしたため) はどうなりますか?

私の観点からの問題は、次の 2 つのクエリがあることです。

まず - cmd.hasErrors() を呼び出すと、たとえば電子メールで一意の制約が永続的に呼び出されます

第二に-サービストランザクションが終了すると、DBへのフラッシュがあり（私の場合、1つのSQL挿入が発生します）、一意の制約を持つ列のメールで例外が発生する可能性があります

テスト cmd.hasErrors() は、DB が違反した制約固有の例外を発生させた場合、または私が間違っている場合を防止しませんか?

4

2 に答える 2

2

これは、リクエスト パラメータをサービス層に渡す最良の方法です。私は、実際には最悪の慣行であるサービスにパラメーターを渡す人々を見てきました。私たちのコントローラーはダンプする必要があります。コントローラーメソッドの最大 5-8 LOC が私の会社のガイドラインです。

コマンドオブジェクトは、バリデーションやメソッドなど、箱から出してすぐに使用できる非常に多くの機能を提供します。

于 2015-10-26T15:01:30.690 に答える
0

データベースから検証する必要がある一意のような制約は、コマンド オブジェクトには適用できません。この場合、バリデータhttp://grails.github.io/grails-doc/2.5.1/ref/Constraints/validator.htmlを使用できます。

importFrom 制約を使用して、すべての制約フォーム ユーザー ドメインからコマンド オブジェクトhttp://grails.github.io/grails-doc/2.5.1/guide/validation.htmlを取得することもできます。

于 2015-10-27T12:08:17.783 に答える