Для нового программиста это нормально / рекомендуется или нет?
Этот вопрос подразумевает, что дизайн / компоненты / архитектура системы выбраны / предназначены для пользы программиста.
Вместо этого я предпочитаю выбирать дизайн / компоненты / архитектуру, чтобы принести пользу системе (и владельцам системы, пользователям и операторам), и гарантировать, что программисты знают (что может потребовать некоторого обучения или обучения с их стороны), что они необходимо для разработки этой системы.
Факты:
- ОО часто является хорошим способом разработки программного обеспечения
- БД SQL часто являются хорошим способом хранения данных
- Проектирование отображения из SQL в OO может быть нетривиальным
Если нет, является ли альтернатива ОО-программе процедурной программой?
Ну, может быть, да: одна из особенностей ОО - это создание подклассов, а подклассы / наследование - это одна из проблем, которую проблематично моделировать / хранить в базе данных SQL.
Например, учитывая OOD как это ...
class Animal
{
int id;
string name;
abstract void eat();
abstract void breed();
}
class Dog : Animal
{
bool pedigree;
override void eat() {...}
override void breed() {...}
}
class Bird : Animal
{
bool carnivore;
int numberOfEggs;
void fly() {...}
override void eat() {...}
override void breed() {...}
}
... неясно, хранить ли эти данные, используя 2 таблицы SQL или 3. Принимая во внимание, что если вы уберете подклассы:
class Dog
{
int id;
string name;
bool pedigree;
void eat() {...}
void breed() {...}
}
class Bird
{
int id;
string name;
bool carnivore;
int numberOfEggs;
void fly() {...}
void eat() {...}
void breed() {...}
}
... тогда проще / более очевидно / более 1 к 1 / точнее моделировать эти данные, используя ровно две таблицы.
Также я не понимаю несоответствие объектно-реляционного сопротивления
Вот статья, которая длиннее и известнее, чем статья в Википедии; может быть, это легче понять: Вьетнам компьютерных наук
Обратите внимание, что одно из решений , которое предлагает проблему, это:
" Ручное отображение. Разработчики просто
признать, что это не так сложно
в конце концов, решить проблему вручную,
и написать прямой реляционный доступ
код для возврата отношений к
язык, доступ к кортежам и
заполнять объекты по мере необходимости. "
Другими словами, на практике это не такая сложная проблема. Это сложная проблема в теории , т. Е. Трудно написать инструмент, который создает отображение автоматически и без необходимости думать об этом; но это верно для многих аспектов программирования, не только для этого.