Can't I use an enum at application level if I have a NxN relationship?

Question

After reading the answers to this question, and this and this related questions, I'm now confused about how/if to work with an enum having an NxN relationship.

Let's say I have an entity Hotel, an my hotels can offer some services: sauna, gym, wifi, etc. Following

You should decide whether your Platform is an entity or not. If it's an entity, it can't be an enum

From here, and

The set of valid values is data, not code

From here, and if I understood it all correctly, my approach to modelling this with the enum in DB is to have a hotels table, a services table, and a junction table hotels_services. The services table would have two columns (id, service) or just one (service). When saving hotel information, the validity of the services would be enforced not by the application but by the DB. My Service class would then have two (Long id, String service) or just one (String service/value) fields. My Hotel class would have a List<Service> services.

So far, kind of good. But if my application's logic depends somehow on the type of service, I would like to have the enum's type safety. That looks hard, because then I would have to convert them to a ServiceEnum enum, which sounds just wrong: somewhere I would need to do the convertion, and there I would need to hardcode the possible values, so duplicity. Then, I have this extra class ServiceEnum that is confusing.

Is this how it's supposed to be? Just give up on using an enum in this case? I can live with it, but I'd like to hear that I need to, or what is it that people do in these cases.

Answer 1

You're confusing two ideas. The relationship between Hotel's and Service's is going to either be one-to-many or many-to-many according to whether Hotel objects have ownership over a Service or if Service's will be commonly shared amongst all Hotel's. You can do it in either way, since they both have pluses and minuses, but the important thing to note is that you could have a potentially unlimited amount of Service's associated with a Hotel.

Today, you have "Room service", "Pool", and "Laundry service" to choose from and tomorrow you'll have "Room service", "Pool", "Laundry service", and "Parking". While you could represent this with enum, it is likely best that you do not. Keep in mind that entries in the Service table now only have a name, but you may later want to add other fields. Service is just as much an entity as Hotel is, so it should be treated thusly.

In other words, you should have a Service class, and not an enum to handle Service instances. Representing Service as a class not only represents that database table better, but it will make future maintenance much easier. Adding say, localizations for each service is only a matter of adding a child table. If you were handling it as an enum, you'd have to keep a static resource bundle that expands to represent new possible ServiceEnum values as you add them to your program, and though you wouldn't realize it, you'd essentially be trying to emulate ServiceEnum in your program as if it were a Service entity anyway.

It all boils down to properly representing this object in your program, and the best way to do that in this case is to treat it like any other entity.