7

私は最初の Grails アプリケーションに取り組んでいます。これには、古い Struts Web アプリケーションの移植が含まれます。多くの既存の機能があり、物事を移動するにつれて、サービスに何を入れるべきか、モデルに直接含めるべきかを決定するのに本当に苦労していますか?

主に Ruby on Rails 開発のバックグラウンドを持っているため、関連するドメイン クラスにほとんどすべてを配置する傾向が強いと感じています。しかし、私が移植しているアプリケーションと同じくらい大きなアプリケーションでは、クラスによっては何千行もの長さになることがあります。

ドメインに入れるものとサービスに入れるものをどのように決定しますか? 確立されたベストプラクティスはありますか? 私は周りを見回しましたが、ほとんどの人は問題を認識しているようです.

4

3 に答える 3

9

一般的に、私が従う主なガイドラインは次のとおりです。

ロジックのチャンクが複数のドメインクラスに関連している場合は、それをサービスに配置します。それ以外の場合は、ドメインクラスに配置します。

扱っているロジックの種類についての詳細がなければ、それよりも深く掘り下げることは困難ですが、ここにいくつかのより一般的な考えがあります。

  1. ビューの表示に関連するものについては、タグライブラリ（またはおそらくサービス）に入れます
  2. ビューに何を送信し、どのビューに送信するかを理解することを扱うものについては、それはコントローラー（またはおそらくサービス）に入ります
  3. 外部エンティティ（つまり、ファイルシステム、キューなど）と通信するものについては、それらはサービスに参加します

一般的に、私は物事をひとまとめにするよりも、サービスが多すぎるという側面で誤解する傾向があります。結局のところ、それはあなたにとって最も理にかなっていること、そしてあなたがコードについてどのように考えているか、そしてあなたがそれをどのように維持したいかについてのすべてです。

ただし、私が注意することの1つは、移植するものにおそらく高レベルのコード重複があるということです。GrailsはGroovy上に構築されており、Closuresなどのより強力なプログラミングメソッドにアクセスできるため、コードの多くをクリーンアップして単純化できる可能性があります。

于 2012-04-04T17:03:12.573 に答える
1

個人的には、サービスとドメイン クラスの間の決定だけでなく、プラグインまたは挿入されたコードの決定でもあると思います。

のような動的ファインダーを考えてみてくださいBook.findAllByName()。Grails がそれらをドメイン クラスに注入するのは素晴らしいことです。それ以外の場合は、各ドメイン クラスにコピーするか、サービス ( dynamicFinderService.findAllByName('Book')-argh) を介して呼び出し可能にする必要があります。

したがって、私のプロジェクトでは、プラグインに移動してドメインクラスに挿入するものがかなりあります...

于 2012-04-05T06:46:51.920 に答える
-1

Java EE の観点から: ドメイン クラス内にロジックはまったくありません。ドメイン クラスはできるだけ簡単で短くしてください。ドメイン モデルはアプリケーションのコアであり、簡単に取得できる必要があります。

  • Grails は依存性注入のために開発されています。ドメイン クラスに存在するすべてのロジックはテストが難しく、リファクタリングが簡単すぎます。
  • サービス (DI) のように実装を交換することはできません。
  • ドメイン クラスのコードを簡単にテストすることはできません。
  • 実装はサービスのようにプールできないため、システムをスケールアップすることはできません。

私の推奨事項: サービス内のすべてのロジックを保持します。サービスは、テスト、再利用、保守、再構成が容易です。

grails に固有: ドメイン クラスを変更すると、インメモリ DB が強制終了されるため、テスト データが失われ、ラピッド プロトタイピングができなくなります。

于 2012-04-04T18:26:01.310 に答える