grailsドメインクラスでクラスメソッドを書くことの長所と短所は何ですか? 私が質問しているのは、ドメイン クラス内にメソッドがあり、データ メンバーだけである grails プロジェクトをよく見かけないからです。そうすることの不利益はありますか?
2 に答える
ドメイン クラス (grails だけでなく、オブジェクト指向プログラミング全般) の場合、これは貧血ドメイン モデルとして知られています。Martin Fowler は、ドメイン ロジックをドメイン クラスに組み込んでリッチなドメイン モデルを作成することを提案しています。これを行うことで、ドメイン クラスは、ドメイン クラスで操作する必要がある別のサービス クラスを持つのではなく、よりスマートになり、操作の実行方法を認識します。豊富なドメイン モデルを持つことの利点は、クラスが独自の動作をより多くカプセル化し、自己完結型になることです。反対に、ドメイン クラスはより複雑になります。ただし、ドメイン クラスは単なるビジネス オブジェクト以上のものであるべきだと思います。
grails では、リッチなドメイン モデルとサービスの使用を組み合わせて使用する傾向があります。メソッドをいつドメイン クラスに配置し、いつサービスに配置するかについて、一概に述べるのは困難です。ただし、原則として、操作が複雑で複数の共同作業者が必要な場合は、サービス クラスに配置する傾向があります。メソッドがドメイン クラスでの動作であるように思われる場合は、そこに配置します。
より具体的な例を挙げるために、Person
クラスを見てみましょう。
class Person {
String firstName
String lastName
List<Person> friends
}
私たちのアプリケーションでは、人は話すことができます。今、私はTalkService
人の話し方を知っている を手に入れることができます。talk
しかし、この場合、それはその人の核となる行動だと思うので、 にtalk
メソッドを追加しPerson
ます。
人の友達のすべての友達(2度の友達)を見つけたい機能もあるとしましょう。私にとって、これは のコア動作ではないPerson
ので、これをサービスに委譲します。
要約すると、一般に、それがオブジェクトのコア動作である場合 (ドメイン メソッドなど) はドメイン クラスにメソッドを追加し、それ以外の場合はサービスに配置します。
Java プロジェクトでは、モデルを表す POJO クラスが必要です。例: 個人、請求書、帳簿など
次に、ユーザーがデータベースクエリを実行するためのインターフェイスを含むサービスレイヤーがあり、モデルのパラメーターを受け取り、モデルを返します。また、リダイレクトとサービスの注入を担当するコントローラーレイヤーがあります。
Grails では、これはコントローラーへのサービスの注入を使用して非常に簡単です。
では、いつドメイン クラス内でメソッドを使用する必要があるのでしょうか。それは、私たちが何をする必要があるかを担当するモデルのみの場合です。たとえば、人物 X の年齢 (生年月日から)、請求書に (リストから) 存在する項目の数などです。現在のオブジェクトのデータを操作する場合にのみ使用してください。
たとえば、保存方法の場合、モデルに追加することはできません
PersonController :
def personService
def save() {
...
Person person = ...
personService.save(person);
...
}
これはより進化的です