3

これらの機能要件を考えると:

ユーザー管理

  1. 管理者
  2. 司書
  3. 借り手

*ユーザーは、OpenID 経由でログインするオプションがあります。

資産管理

  1. 本
  2. メモ
  3. 円形
  4. ライセンス

通常、これらを Java で次のように実装します。

interface User {}
class Librarian implements User {}
class Administrator implements User {}
class Borrower implements User {}

class OpenID {} //all Users HAS AN OpenID attribute (NULL if non-openId login)

interface Property{}
class Book implements Property{}
class Memorandum implements Property{}
class Circular implements Property{}
class License implements Property{}

しかし、私たちのプロジェクトでは、まだ使用経験のない Groovy & Grails を使用します。私の質問は、上記の要件に基づいてドメインクラスをどのように設計する必要があるかということです。インターフェイスを使用できません。継承は適切ではないようです。私の考えは、生成されるデータベース テーブルにかなり悩まされていますが、compositionを使用することです。この状況でのベストプラクティスは何ですか?

4

1 に答える 1

12

まず第一に、それを修正しましょうinheritance。この場合に使用できます。has a関係から関係への規則を変更するだけですis a。

注意すべきいくつかの要因: 1. Grails は、構成よりも規則に従って動作します。2. 永続層をラップし、Hibernate の助けを借りて基礎となる永続層のオブジェクト マッピングを作成する GORM を使用できます。

機能要件に従って:-

User永続化の一部として使用したくない場合は、属性を含むユーザーの共通プロパティを保持できるabstract クラスを使用できます。慣習に従ってディレクトリに配置する必要があります（基本クラスは抽象であるため、依存性注入は拒否されます）UseropenIdsrc\groovy

についても同様ですProperty。の抽象Propertyクラスsrc\groovy。

ここで、親からのextend各具体的なエンティティ (domainクラス)のビジネス モデルについて説明します。abstract

概要：-

  • grails アプリを作成する

  • src\groovy の下 (たとえば、基本的な構造を検討しています):

User.groovy:-

abstract class User{
    String name
    String emailId
    OpenID openId
}

Property.groovy:-

abstract class Property{
    String propertyName
}
  • 下grails-app/domain：

Librariran.groovy:-

class Librarian extends User{
   //Attributes specific to Librariran
   static constraints = {
   }

   static mapping = {
   }
}

Book.groovy:-

class Book extends Property{
    //Attributes specific to Book
       static constraints = {
       }

       static mapping = {
       }
}

などなど。grails-app/domain の下にある Groovy オブジェクトは、Grails の規則によって具体的なエンティティと見なされます。あなたが明らかにここで見つけることができるより多くの情報。シナリオに出くわした場合は、構成を使用することもできますUser。実際、 OpenId.

注:- これは Grails の最新バージョン (> 2.x) のコンテキストです。

于 2013-05-01T03:40:22.983 に答える