Question

I have a db with the following tables Items, Groups and GroupItems. The Items table contains the settings of each item, the groups table contains the definition of some groups and the GroupsItems table contains the link of each item to each group and the date when the item was added to the group and the date when the item was removed (if any).

In my C# model I have 3 classes:

• class Item
• class Group
• class GroupItem

The class Group has a collection of GroupItems and each GroupItem class contains one Item and the date added and removed if any.

I’m not sure if this is a good design or if I’m moving the DB structure to my application model. Would be better if I move the two dates directly to the class Item and I reduce the number of classes by one and thus the software complexity?

What do you think?

Answer 1

If you can by removing the GroupItem class and “splitting” it in Item in your architecture, it’s a good choice.
The only thing you have to consider, that you have to remap your DB mapping at this point.

The choice here is between clean architecture of your app and clean mapping between your app and DB.

I, personally, would stand for clean mapping and leave the stuff as is. As after a couple of month you will never remember which fild where binded, and having already relatively coherent mapping between your code model and db model will help make the all stuff easier to understand, imo.