Best way to structure C# Class

Question

I have the following Classes;

public class Hotel
{
   public int HotelId {get; set;}
   public string Name {get; set;}
   public string Address {get; set;}
   public string City{get; set;}
}

public class District
{
   public int DistrictId {get; set;}
   public string Name {get; set;}
}

Then I need a class that can hold both DistrictId and HotelId as a pair so I thought of creating a class like below

public class HotelDistrict
{
   public int DistrictId {get; set;}
   public int HotelId {get; set;}
}

Is this the correct way to go ? Or is their a better alternative ?

Answer 1

That looks to much to a database table design. In OOP world, you normally add references to classes instead of just to ids.

Something like this

public class HotelDistrict
{
   public Distric District {get; set;}
   public Hotel Hotel {get; set;}
}

There is no silver bullet so there are exceptions for this rule but normally you want to avoid creating classes that smell so much to database tables.

Answer 2

Hotel and District have many to one relationship. So, Hotel should have mapping to its corresponding District -

public class Hotel
{
   public int HotelId {get; set;}
   public string Name {get; set;}
   public string Address {get; set;}
   public string City{get; set;}
   public int DistrictId{get; set;}
}

Answer 3

You could simply store a reference to District in your Hotel or a List<Hotel> in your District. Typically, unless you are dealing with writing database models, you should not retain unique identifiers as you are doing. If this is a database model, then your solution is fine assuming you need to support a hotel in more than one district.

Answer 4

For any reason, if you really need to go with the original HotelDistrict way, you actually don't need a new class, you could just use a Tuple<Hotel, District> to store pairs, and a list of those tuples (such as List<Tuple<Hote, District>>) to store a list of those pairs.

But as Rohit Vats stated, there is a *-1 relationship so it's better to have a reference to the district as a field, so I recommend his approach if you don't have a specific reason for using your original approach.

Answer 5

As an alternative to the other excellent answers here you can also do the following if you prefer a more explicit domain model with loosely coupled objects. (I assume every single hotel can only be in one district at a time.)

class Hotel
    int HotelId
    int DistrictId
    ...

class District
    int DistrictId
    ...

class HotelsInDistrict
    int DistrictId
    List<int> HotelIds

The upside: It's loosely coupled, you don't need to fiddle with painful stuff like huge object graphs, lazy/eager loading and stuff. It' along the lines of the actual business domain instead of just data containers. It's loosely coupled and allows easy modification.

The downside: It doesn't easily maps to yourt database tables. But no real object model does if it's more than a data oriented bunch of "classes" that are mere representations of tables.

That said, there's a book I really recommend to everyone interested in object modelling:

• Streamlined Object Modeling: Patterns, Rules, and Implementation