grails - ビジネスロジック用にアプリケーションサーバーとGrailsフレームワークを分離しますか?

Question

Grails ドメイン モデル/サービスを使用してビジネス ロジックを含めるか、Grails コントローラー/サービスをアプリケーション サーバーと通信させ、Web レイヤーをアプリケーション ロジック レイヤーから分離するかの違いについて、少し混乱していますか?

1. いつどれを選択するのですか？
2. 各アプローチの長所と短所は何ですか?
3. スケーラビリティのために特別に Grails ドメインのものを使用している問題はありますか?

Answer 1

ドメインとビジネス ルールを処理する Web サービスが既にある場合は、db サポートをオフにすることができます。

これを行うと、Grails アプリは事実上、別のサービスの上にある薄い Web レイヤーになります。この場合、ビジネス ルールを適用する場合は、サービス/ドメイン レイヤーで実行できます。ただし、サービスはアプリの信頼できる唯一の情報源である必要があり、2 つのアプリでビジネス ルールを重複させたくないため、これは行いません。また、複雑な検証も行いません。

Web リクエストの処理には引き続きコントローラーを使用し、他のサービスとの対話にはサービスを使用します。また、Web層のセクションを介してデータを渡すための単純なドメイン層もあります（つまり、サービスは貧弱なドメインオブジェクトを返し、コントローラーはそれらをクライアントにシリアル化しますが、理にかなっています）。作業の大部分は、他のサービスとの通信をシリアル化および逆シリアル化するサービス層で行われます。

あなたのコメントに基づいて、Grails はサーバー層を構築するための優れたテクノロジです。なぜそうではないと思いますか？Grails は、迅速な開発環境であると自負しています。標準 Web アプリのすべてのレイヤーに必要なすべてを提供します。何も失うことはありません。まったく逆に、永続性、スプリング、堅牢なテスト フレームワークなどとの統合など、かなりのメリットがあります。