2

I'm currently developing on a rather large e-commerce application that handles multiple different business-fields. Like every e-commerce application we have a Concept called an Order which has one or more OrderItems.

Due to the fact that we cover multiple business-fields the OrderItems need to store different Information based on the business-field the customer placed it, this is currently done using Class Inheritance on the Application-Part and Single-Table-Inheritance on the Database-Part.

Here's a quick and very simplified example:

class OrderItem {
  int amount;
  int created_at;
  int order_id;
}

class ElectronicOrderItem extends OrderItem {
  string brand;
  string description;
}

class RentalOrderItem extends OrderItem {
  date startDate;
  date endDate;
  enum type;
}

The table OrderItem now contains all fields of all subclasses nullable if not for the specific type. This seemed like a good idead when the application started a few years ago but now is very clumsy with way to much nullable columns ~75.

I'm now trying to figure out the best way to refactor this code-part with the perspective that the application may be split up into different parts (business fields) most likely.

My current approaches would be one of the following:

  1. use CTI supported by the ORM we're using and create a Table for each of the subclasses of order-item.

  2. create a completely new Entities

like:

class ElectronicOrderItem {
  OrderItem item;
  string brandname;
  string description;
}

I'm not sure which option would be better especially when thinking about the fact that the team is growing and the application might be split apart into single services in the next few years.

1

Given:

the application may be split up into different parts (business fields) most likely.

and

the application might be split apart into single services in the next few years

I would be reluctant to do anything based on the above. Who knows what will happen in the near future, and I'd be wary of basing any design on what is predicted to happen in such timescales. I would look at what problems you're facing now and address those.

Looking at your issue of modelling the classes, as a general rule I would favour composition over inheritance. That will buy you more flexibility, and given the uncertainty of where your application is going, that can only be a good thing.

0

So you want to normalise your DB to cope with the subclasses - I'd say that makes sense. Its easy to do, you create views or stored procs to expose the new DB schema to the old application as if nothing had happened and work on modifying the DB tables as much as you like.

When that's complete, you can modify the application to start reading from the new tables directly (or simpler views - you never know when you'll want to repeat this process or when you need to update the DB for one team while keeping compatibility for another)

  • Hi thanks for your input on migrating the data, but my question was which of the 2 options I gave are the more viable in your opinion. – gries May 4 '16 at 11:38
  • 1
    I thought it might be clear on the answer. 1 is easiest to migrate to and maintain afterwards, though I don't know what your ORM supports to give you the best answer. – gbjbaanb May 4 '16 at 12:27

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.