C ++ DAL Design - включить таблицу внешних ключей в качестве составного объекта - PullRequest
Новая
       27

C ++ DAL Design - включить таблицу внешних ключей в качестве составного объекта

0 голосов
/ 06 октября 2009

Я недавно опубликовал этот C ++ DAL вопрос о том, как лучше всего спроектировать метод loadCar в C ++ DLL, с единодушным мнением, что 'bool DAL :: loadCar (int id, Car &) {} 'будет лучшей подписью для использования.

Теперь, случается, что во многих наших случаях использования клиентский код часто хочет получить производителя автомобиля с помощью объекта автомобиля. Таблица 'car' в базе данных имеет внешний ключ (MANUFACTURER_ID) для таблицы производителя. Теперь я думаю о наличии дополнительного поля в классе Car, например: 

class Car
{
  public:
    void setModel(...);
    void setEngineSize(...);
    Manufactuer getManufacturer();

  private:
    Manufactuer /* Reference, Pointer or Value - TBD */ manufacturer_;

  // etc.
};

Вопрос в том, будет ли у вас закрытый член производителя в качестве указателя, ссылки или простого типа значения, то есть одного из: 

Manufactuer *manufacturuer;
Manufactuer &manufacturuer; // Illegal - needs to be initialised, so use Null Obj Pattern?
Manufactuer manufacturuer;

Теперь метод loadCar будет иметь параметр bool loadManufactuer (по умолчанию false). То есть мы только хотим, чтобы стоимость и затраты на хранение загружали производителя время от времени. Это заставляет меня думать, что я должен хранить производителя как указатель (1-й вариант).

Обратите внимание, причина, по которой я не делаю композицию на более высоком уровне, заключается в том, что я хочу, чтобы DAL мог составлять производителя автомобилей + с помощью одного запроса к базе данных. Обратите внимание, что, хотя здесь и не показано, пользователь может запросить коллекцию объектов Car.

Я не был уверен в использовании указателя, так как мне кажется, что я сейчас смешиваю указатели со ссылками, но не могу понять, как это можно сделать в противном случае без введения большого количества временных переменных. Может быть, Нулевой Объект Singleton поможет?

Надеюсь, что это имеет смысл.

Ответы [ 2 ]

1 голос
/ 06 октября 2009

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

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

1 голос
/ 06 октября 2009

Вы должны принять немного другой подход, который я чувствую. почему бы не иметь идентификатор производителя в объекте Car? Если в какой-то момент нужен производитель, тогда загрузите через id. Вы можете скрыть это ленивой загрузкой.

В основном есть объект производителя, который заполняет поля, только если к этим полям обращаются.

...