Моделі на одну таблицю бази даних?

Я використовую кодигнайтер, і опинився в подібній ситуації, коли я повторив Модельні методи. Я створюю модель на контролер. Але я б створив модель «Модель за таблицею баз даних», вважаючи доброю практикою? Таким чином методи не пишуться двічі.

Замість моделі за контролером або декількох малих моделей, які спільно використовуються.

Наприклад, якщо у мене є модельний метод get_user ($ user_id), я міг би написати його на users_models.php ...

Одним із недоліків, які я бачу в цьому, є те, що мені, можливо, доведеться викликати кілька моделей, а не просто контролерname_models.php.

Чи може завантаження декількох моделей, коли кілька контролерів не можна використовувати з контролера, впливати на продуктивність та швидкість? Що може бути найкращим способом вирішити цю проблему?

Примітка. Існують подібні запитання, але вони не охоплюють основу моделі за таблицею баз даних.

Я кажу, що модель за столом просто відтворює вашу базу даних в структурі класів. Він відомий як анемічна модель і вважається антидіаграмою. Це тому, що класи покликані мати як дані, так і поведінку. Якщо ви обмежуєте свої моделі однією таблицею, куди ви ставите код (поведінку), який потребує обробки даних та поведінки з кількох таблиць? Тоді вашим контролерам знадобляться моделі, які використовують одну або декілька з цих «настільних» моделей ... Отже, за винятком найпростіших програм, від такого підходу ви нічого не отримуєте.

Як правило, ви повинні створювати свої моделі не за столом або за контролером, а за бізнес-об’єктом. Іноді це може бути співвідношення 1: 1 зі структурою ваших таблиць або з контролерами, але це не обов'язково.

У вашому прикладі може бути один users_modelклас, який викликається з декількох контролерів. Це добре, а іноді навіть бажано. Однак у більшості випадків users_modelклас отримує свої дані з кількох таблиць.
Наприклад, last_login_dateвластивість users_modelкласу можна ( не обов'язково ) отримати з окремої user_auditтаблиці, яка має відношення «один до багатьох» з основною usersтаблицею.

І я б сказав, якщо у вас є одна таблиця SQL на бізнес-об’єкт, то, швидше за все, структура вашої бази даних не нормалізується.

Я здебільшого погоджуюся з відповіддю Діме про те, що ви хочете створити свої моделі за кожним бізнес-об'єктом - проблеми, які намагається вирішити бізнес, повинні впливати на створення модельних класів. На практиці я виявив, що створення однієї моделі за столом - це гарне місце для початку. Правильно розроблена схема, ймовірно, імітує бізнес-процеси, які потрібно моделювати в коді програми - також називається Доменна модель.

Використання шару об'єктово-реляційного картографування корисно, щоб ваша модель домену містила ті ж відносини, що і схема бази даних, без необхідності повторюваних викликів до рівня доступу до даних. Ознайомтеся з красномовним прикладом для PHP. І схема, і модель домену повинні бути розроблені для підтримки бізнес-процесів.

Це призводить до першої частини відповіді Мар'яна Венеми:

Я кажу, що модель за столом просто відтворює вашу базу даних в структурі класів. Він відомий як анемічна модель і вважається антидіаграмою.

Домен Модель анемічний є анти-патерн. "Модель за таблицею", як вважає Венема, може розглядатися як "відтворення вашої бази даних", проте абсолютно невірно сказати, що це лише Anemic Domain Model.

Від Мартіна Фаулера:

Основний симптом анемічної доменної моделі полягає в тому, що спочатку рум'яна виглядає як справжня річ. У доменному просторі є об'єкти, багато яких названі іменами, і ці об'єкти пов'язані з багатими відносинами та структурою, які мають справжні доменні моделі. Зловживання відбувається, коли ви дивитесь на поведінку, і ви розумієте, що навряд чи є поведінка на цих об'єктах, що робить їх трохи більше, ніж мішків геттерів та сетерів.

(наголос, мій)

Ключовим фактором анемічної моделі домену є відсутність поведінки чи методів у класах Доменної моделі.

Це тому, що класи покликані мати як дані, так і поведінку. Якщо ви обмежуєте свої моделі однією таблицею, куди ви ставите код (поведінку), який потребує обробки даних та поведінки з кількох таблиць?

Знову ж таки, ви можете і потрібно вводити поведінку у ваші доменні моделі, навіть якщо вони відображають лише одну таблицю. Поведінка, яка впливає на кілька таблиць, дійсно впливає на кілька об'єктів, які трапляються для відображення в декількох таблицях. Дизайн, керований доменом, - це підхід до точно тієї ж проблеми, про яку згадувала Венема: "куди ви ставите код (поведінку), який потребує обробки даних та поведінки з кількох таблиць?

І відповідь - сукупний корінь . Мартін Фаулер заявляє:

Агрегат - це модель у дизайні, керованому доменом. Сукупність DDD - це кластер об’єктів домену, який можна розглядати як єдину одиницю. Прикладом може бути замовлення та його позиції. Це будуть окремі об'єкти, але корисно трактувати замовлення (разом із його позиціями) як єдиний сукупність.

(наголос, мій)

"Кластер об'єктів домену" також може розглядатися як "Доменні моделі, які відображають у кілька таблиць". Поведінка, яка впливає на декілька таблиць, повинна визначатися в агрегованому корені - класі, який інкапсулює "річ", яка впливає на кілька таблиць або об'єктів:

Знову від Мартіна Фаулера:

Сукупність часто буде містити неоднозначні колекції разом з простими полями.

Щоб відповісти на оригінальне запитання ОП:

... Чи вважати створення моделі на основі таблиці баз даних гарною практикою? Таким чином методи не пишуться двічі.

Я б сказав, що це хороше місце для початку, але пам’ятайте, що ваша схема та об’єктна модель не повинні відповідати 100%. Об'єктна модель повинна більше стосуватися впровадження та виконання правил бізнесу. Схема повинна бути більш орієнтована на зберігання бізнес-даних модульним та масштабованим способом.

Модель на контролері не була б хорошою практикою, хоча існує версія моделі під назвою View Model, яка вписується в рівень Controller. View Model є реорганізація моделі предметної області , щоб відповідати певний вид дисплея, будь то веб - сторінки або форми в додаток з графічним інтерфейсом.