Approach for commercial documents classes

About commercial documents, As you know, a quote, delivery note and an invoice is almost the same with some little fields of difference. In our previous development framework, all commercial documents inherits from a CommercialDocument class, with a discriminatory field to know if this record is an invoice or a delivery note, for example.

Now that we want to migrate to CUBA and all database and model will be rebuilt from scratch, I’m not sure if follow the same approach, or work with a new model with different classes and tables for each commercial document.

Just asking for advice about what do you think in terms of advantges and cons of both methods.

Hi @giuseppe,

I would recommend creating a hierarchy of entities with SINGLE_TABLE or JOINED strategy. So it would be as you described for your previous framework. Then you can avoid code duplication and be able to create generic mechanisms working with all documents through CommercialDocument.

If the number of subclasses of CommercialDocument and their specific attributes is not very large, I would recommend using SINGLE_TABLE inheritance. It saves from additional joins in selects and from problems with unique indexes and soft deletion discussed here.

You can find an example of such approach (with JOINED strategy) in the sample-entity-inheritance project.

1 Like

I will take a look, thanks.