Лучший способ структурирования C# Класс

Question

У меня есть следующие классы;

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;} 
} 

Тогда мне нужен класс, который может содержать как DistrictId и HotelId как пара, так что я думал о создании класса, как показано ниже

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

Является ли это правильный путь? Или их лучшая альтернатива?

Answer 1

Это очень похоже на дизайн таблицы базы данных. В мире ООП вы обычно добавляете ссылки на классы, а не только на ids.

Что-то вроде этого

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

Там нет серебряной пули, так есть исключения для этого правила, но обычно вы хотите, чтобы избежать создания классов, которые пахнут так много таблиц базы данных.

Answer 2

Вы можете просто сохранить ссылку на District в вашем Hotel или List<Hotel> в вашем District. Как правило, если вы не имеете дело с написанием моделей баз данных, вы не должны сохранять уникальные идентификаторы, как вы это делаете. Если это модель базы данных, то ваше решение в порядке, если вы хотите поддержать гостиницу в более чем одном районе.

Answer 3

Отель и район имеют many to one relationship. Таким образом, отель должен иметь отображение в соответствующий район -

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 4

По любой причине, если вам действительно нужно идти с оригинальным HotelDistrict образом, вы на самом деле не нужен новый класс, вы могли бы просто использовать Tuple<Hotel, District> для хранения пар и список этих кортежей (например, List<Tuple<Hote, District>>) для хранения списка этих пар.

Но, как заявила Рохит Ватс, существует соотношение * -1, поэтому лучше иметь ссылку на район как поле, поэтому я рекомендую его подход, если у вас нет конкретной причины для использования вашего первоначального подхода ,

Answer 5

В качестве альтернативы другим отличным ответам здесь вы также можете сделать следующее, если вы предпочитаете более явную модель домена с слабо связанными объектами. (Я полагаю, каждый отель может быть только в одном районе в то время.)

class Hotel 
    int HotelId 
    int DistrictId 
    ... 

class District 
    int DistrictId 
    ... 

class HotelsInDistrict 
    int DistrictId 
    List<int> HotelIds 

Достоинства: Это слабосвязанное, вам не нужно возиться с болезненной вещью, как махина графы, ленивой/жадной загрузка и вещи. Он «по существу», а не только для контейнеров данных. Он слабо связан и позволяет легко модифицировать.

Недостаток: он не легко сопоставляется с вашими таблицами базы данных. Но никакая реальная объектная модель не делает, если это больше, чем ориентированный на данные куча «классов», которые являются просто представлениями таблиц.

Тем не менее, есть книга, которую я очень рекомендую всем, кто интересуется моделированием объекта:

• Streamlined Object Modeling: Patterns, Rules, and Implementation