如何在Grails中设计域类？ [英] How to design domain classes in Grails?

问题描述

用户管理 b

1. 管理员


2. 图书管理员


3. 借阅者

*用户可以通过OpenID登录。

物业管理

$ b

1. 预订
   
2. 备忘录


3. 通告


4. 许可证

通常情况下，我会在Java中实现这些功能：

  interface用户{} 
类Librarian实现User {} 
 class管理员实现User {} 
类Borrower implements User {} 
 
 class OpenID {} //所有用户具有OpenID属性（如果非openId登录，则为NULL）
 
接口属性{} 
类Book实现属性{} 
班级备忘录实现Property {} 
 class Circular implements Property {} 
 class许可证实现Property {} 
  

Bu我们的项目将使用Groovy& Grails，我还没有经历过。我的问题是，
如何根据上述要求设计域类？我不能使用接口，而且看起来继承不是一个好习惯。我的想法是使用组合，尽管我很担心会生成数据库表。这种情况下的最佳实践是什么？

首先让我们改正它，您可以使用继承在这种情况下。您只需要将关系的约定更改为关系为关系。

几个要注意的因素：
1. Grails在约定优化配置方面起作用。
2.您可以使用GORM封装持久层，并在Hibernate的帮助下为底层持久层创建一个Object Mapping。

根据您的功能要求： -

如果你不想让 User 作为持久性的一部分，你可以使用 abstract class User 它可以包含用户的公共属性，包括 openId 属性。它必须按照惯例放置在 src \groovy 目录中（因为基类是抽象的，依赖注入将被拒绝）



Property 也是如此。摘要属性在 src\groovy 中的类

现在来看业务模型，从每个具体实体（ domain 类） >摘要

父母。

摘要： - $ /
$ b

• 创建grails应用程序




• 在src\groovy下（例如，我在考虑基本结构）：

User.groovy： -

 抽象类用户{
字符串名称
字符串emailId 
 OpenID openId 
} 
  

Property.groovy：

 抽象类属性{
字符串属性名
} 
  

• 在下grails-app / domain
  
  Librariran.groovy：
  
  

   类图书管理员扩展用户{
   //特定于Librariran的属性
  静态约束= {
  } 
   
  静态映射= {
  } 
  } 
    

  Book.groovy： -
  
  

    class Book扩展属性{
   //特定于Book 
  静态约束的属性= {
  } 
   
  静态映射= {
  } 
  } 
    

  等等等等。 grails-app / domain下的Groovy对象被Grails约定视为具体实体。您可以在此处找到更多信息。如果你遇到过场景，你也可以使用合成，实际上我已经提到 User 具有 OpenId 。 p>
  
  

  注意： - 这是最新版本的Grails（> 2.x）的上下文。

  
  

  Given these functional requirements:

  User Management

  1. Administrator
  2. Librarian
  3. Borrower

  *The users have the option of logging-in via OpenID.

  Property Management

  1. Book
  2. Memorandum
  3. Circular
  4. License

  Normally, I would implement these in Java as:

  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{}
  

  But our project will use Groovy & Grails, which I haven't experience using yet. My question is, how should the domain classes be designed based on the requirements above? I can't use an interface, and it seems inheritance is not a good practice. My idea is to use composition, though I'm quite bothered by the database tables that would be generated. What are the best practices in this situation?

  解决方案

  Well first of all lets correct it, you can use inheritance in this case. You just need to change the convention of has a relationship to is a relationship.

  Few factors to keep note of: 1. Grails works on convention over configuration. 2. You can use GORM which wraps the persistence layer and creates an Object Mapping for the underlying persistence layer with the help of Hibernate.

  As per your functional requirement:-

  If you do not want to have the User as part of persistence you can have an abstract class User which can hold the common properties of the User including the openId attribute. It has to be placed in src\groovy directory as per convention (since the base class is abstract, dependency injection will be defied)

  The same goes for Property. Abstract Property class in src\groovy.

  Now coming to the business models, extend each of the concrete entities (domain classes) from the abstract parent.

  Summary:-

  • Create grails app

  • Under src\groovy(for example, I am considering a basic structure):

  User.groovy:-

  abstract class User{
      String name
      String emailId
      OpenID openId
  }
  

  Property.groovy:-

  abstract class Property{
      String propertyName
  }
  

  • Under 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 = {
         }
  }
  

  So on and so forth. Groovy objects under grails-app/domain are considered concrete entities by Grails convention. More information you can obviously find here. You can also use composition if you come across scenarios, in fact I already mentioned that in User having OpenId.

  Note:- This is context to latest version of Grails (> 2.x)

  这篇关于如何在Grails中设计域类？的文章就介绍到这了，希望我们推荐的答案对大家有所帮助，也希望大家多多支持IT屋！