2012-01-07 2 views
1

Использование C# 4.0Моделирование многие-ко-многим в коде

Исходя из моего вопроса How to configure nHibernate for many-many mapping? я путаюсь, и это может быть потому, что мой класс дизайн является неправильным.

Рынок моделирует финансовый рынок. Брокер моделирует финансового брокера, который может взаимодействовать со многими рынками. Рынок может взаимодействовать со многими брокерами. См. Ниже классы Broker и Market.

public class Market 
{ 
    public int Id { get; set; } 
    public string Symbol { get; set; } 
    public string Description { get; set; } 
} 

public class Broker 
{ 
    public int Id { get; set; } 
    public string Name { get; set; } 
    public bool IsDefault { get; set; } 
    public bool IsActive { get; set; } 
    public IList<Account> Accounts { get; set; } 
} 

У меня есть дополнительный атрибут в многие-ко-многим называется MinIncrement, который является уникальным для Market и Broker комбинации.

Каков наилучший способ моделировать это? Нужно ли создавать третий класс или я могу поставить MinIncrement в один из моих существующих классов? Должен ли я создать третий класс и наследовать от одного из моих существующих? Я не совсем уверен, как моделировать это способом OO.

В моей базе данных все просто. У меня есть три таблицы:

  • брокеры (PK: brokerId)
  • рынки (PK: marketId)
  • brokerMarkets (PK: brokerId, marketId), колонка MinIncrement идет здесь

ответ

1

Да , Я бы создал третий объект:

public class BrokerMarketRelationship 
{ 
    public int Id { get; set; } 
    public Broker Broker { get; set; } 
    public Market Market { get; set; } 
    public int MinIncrement { get; set; } 
} 
+0

Спасибо за ответ, вы можете объяснить, почему вы выбрали это решение над другими, например, наследование или лизис т брокеров в рыночном объекте и список рынков в брокерском объекте? –

+0

Вы можете иметь отношения «многие ко многим», как вы говорите, с коллекцией с обеих сторон, но вы не сможете легко обслуживать свойство MinIncrement. Я не уверен, что вы имеете в виду, используя «наследование». Если MinIncrement определенно является свойством взаимоотношений между брокерами и рынками, то вы должны дать отношение его собственной сущности. Так я все равно. Многие-ко-многим могут быть немного раздражающими в NHibernate. Предоставляя отношения своему собственному сущности, вы разбиваете «много-ко-многим» на два отношения «один-ко-многим», которые, как я лично считаю, облегчают жизнь. – cbp

+0

В моем примере я знаю, что вы теряете способность однозначно применять комбинацию Брокер/рынок в своей БД с использованием первичного ключа. Если вы deseparate, вы можете добавить отдельное уникальное ограничение, или вы можете попробовать и реализовать составной ключ вместо использования столбца суррогатного идентификатора в объекте «Связь». Первое может повлиять на производительность, но может быть и в порядке, в зависимости от вашего сценария. Последнее возможно в NHibernate, но лично мне кажется проблематичным работать. В зависимости от сценария я могу отказаться от уникальности на уровне базы данных. – cbp

Смежные вопросы