0

I'm investigating a personal Grails project and want to put together a domain model to represent a product catalog. I really can't decide the best way to go about it. I will have a number of different product categories although many categories will just have a base set of properties that are shared across all categories (e.g. product name, product description, price etc). However, some products will have additional properties specific to their category.

I've looked into the Entity Attribute Value (EAV) Model technique that provides a very extensible solution. And, I've considered the route of using an explicit OO inheritance model where I have sub-classes of a base Product class to represent any product that has additional properties.

Obviously, the second approach is less extensible - to add a new product category would require a new entity and likely a custom view/editor for the front-end. However, as a developer, I think the programming model is significantly clearer and much more logical to code against.

The EAV approach would allow dynamic extensibility but would lead to a more cryptic programming model and would have a performance overhead in the DB (complex table joins). Views/editors on the front end could be dynamically generated to include any number of the custom attributes for a product category - though I'm sure situations would arise where such dynamic generation wouldn't suffice from a usability perspective.

When I consider a framework like Grails, it would seem to make sense to go down the route of creating an explicit inheritance model. I'm not convinced a framework like Grails would fit the EAV approach so well - a lot of the benefits of Grails would be lost in the complexity. However, I'm not sure this approach would scale practically as the number of product categories increases.

I'd be really interested to hear of others' experience with this type of modelling challenge!

DrewEaster
  • 3,316
  • 3
  • 35
  • 39

2 Answers2

0

I’ve had a situation similar to this and went with the inheritance solution. Going into this I knew I’d never have more than about 10 classes so I wasn’t worried about exponential growth of complexity. Although you will need views and controllers for each class there are some things you can do to reduce code duplication. The first thing to do is to put all common view code in templates. For example if all your classes will have a price, name, and description the view code that will allow the displaying and editing of this should be put into templates. Instead of having duplicate lines of code in each view you can simply do a

<g:render template=”/baseView</g>render>

For more info on templates see http://www.grails.org/Tag+-+render The second thing I found useful to do was move all shared controller code into a class and define closures that I could call from my actual controller. This got quite ugly since my save method would not only insure the fields of the base class were dealt with properly but would also have code for corner cases of the inherited classes. Looking back on this a better option may have been to define custom behavior as functions of the domain class that required it or to use a service. With that said putting code into closures that could be called from the controller was still helpful since it would allow me to have one line long controller bodies instead of 30 or 40. If I had to modify code dealing with the base class I could edit it where the closures were defined and that change would be reflected across all my controllers with no code change to the actual source file of the controller. This came in quite useful and allowed me to edit code in one place instead of editing duplicate code across 10 controllers.

Jared
  • 39,513
  • 29
  • 110
  • 145
  • Thanks, some really useful ideas here. I do feel the inheritance route feels more comfortable. Like in your situation, I don't think the number of entities will reach a point where it would become a problem. – DrewEaster Dec 06 '10 at 15:15
  • One question...if I wanted a resource path to lookup products, e.g. /products/{productId}, how would I know which product entity to lookup and, correspondingly, which view to render? Would be interested to now how you solved this. – DrewEaster Dec 06 '10 at 17:19
  • I didn't have to do this with my program. I assume you could use a generic product controler, do a BaseClass.get(id) test for the class type, then redirect to the proper controler. – Jared Dec 06 '10 at 17:24
  • Cool, I was thinking along those lines but would prefer to avoid the additional query - however, it's hardly a major overhead. – DrewEaster Dec 06 '10 at 17:37
0

Inheritance works fine with Hibernate and GORM. Consider using the table-per-subclass mapping as you cannot define NOT NULL constraints with the (default) table-per-hierarchy inheritance mapping.

You can also use composition for "not so" common, but shared, attributes.

"The" criteria for EAV is, do you need to introduce new attributes without changing the data model?

In practice, applications like yours use a combination of inheritance and EAV.

You're concerned about performance when querying JOINed tables. That's normally not an issue if you index the columns that are included in the SQL WHERE statement.
(GORM/Hibernate will automatically create foreign keys, which are important as well.) (Given, the necessary indexes are in place and a DBMS that provides a decent query optimizer (i.e., PostgreSQL oder SQL Server - maybe not MySQL), you can select from millions of records using 10 joins in 50 milliseconds or less.)

Finally, there's been an excellent, recent, discussion on your issue.

Community
  • 1
  • 1
robbbert
  • 2,183
  • 15
  • 15