Given these functional requirements:
User Management
- Administrator
- Librarian
- Borrower
*The users have the option of logging-in via OpenID.
Property Management
- Book
- Memorandum
- Circular
- 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 ofhas a
relationship tois 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 anabstract
classUser
which can hold the common properties of the User including theopenId
attribute. It has to be placed insrc\groovy
directory as per convention (since the base class is abstract, dependency injection will be defied)The same goes for
Property
. AbstractProperty
class insrc\groovy
.Now coming to the business models,
extend
each of the concrete entities (domain
classes) from theabstract
parent.Summary:-
Create grails app
Under src\groovy(for example, I am considering a basic structure):
User.groovy:-
Property.groovy:-
grails-app/domain
:Librariran.groovy:-
Book.groovy:-
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
havingOpenId
.Note:- This is context to latest version of Grails (> 2.x)