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

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

Вместо модели на контроллер или несколько небольших моделей, которые являются общими.

Пример, если у меня есть метод модели get_user ($ user_id), я мог бы написать его на users_models.php ...

Один из недостатков, которые я вижу, заключается в том, что мне, возможно, придется вызывать несколько моделей, а не просто controllername_models.php.

Может ли загрузка нескольких моделей, где несколько методов не могут быть использованы из контроллера, повлиять на производительность и скорость? Что может быть лучшим способом справиться с этим?

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

Я говорю, что модель на таблицу просто воссоздает вашу базу данных в структуре классов. Это известно как анемичная модель и считается анти-паттерном. Это потому, что классы должны иметь как данные, так и поведение. Если вы ограничиваете свои модели одной таблицей, куда вы помещаете код (поведение), который должен иметь дело с данными и поведением из нескольких таблиц? Тогда вашим контроллерам потребуются модели, использующие одну или несколько из этих «табличных» моделей ... Так что, кроме самых основных приложений, вы мало что выиграете от этого подхода.

Как правило, вы должны создавать свои модели не для таблицы или контроллера, а для бизнес-объекта. Иногда это может быть отношение 1: 1 с вашей структурой таблиц или с вашими контроллерами, но не обязательно.

В вашем примере у вас может быть один users_modelкласс, который вызывается из нескольких контроллеров. Это хорошо, а иногда даже желательно. Однако в большинстве случаев users_modelкласс будет получать свои данные из нескольких таблиц.
Например, last_login_dateсвойство users_modelкласса может ( не обязательно ) быть получено из отдельной user_auditтаблицы, которая имеет отношение «один ко многим» с основной usersтаблицей.

И я бы сказал, что если у вас есть одна таблица SQL на бизнес-объект, то, скорее всего, ваша база данных не нормализована.

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

Использование слоя Object / Relational Mapping полезно, так как ваша модель домена содержит те же отношения, что и схема базы данных, без необходимости повторных обращений к уровню доступа к данным. Проверьте Eloquent для PHP в качестве примера. Как схема, так и модель предметной области должны быть разработаны для поддержки бизнес-процессов.

Это приводит к первой части ответа Марьян Венема:

Я говорю, что модель на таблицу просто воссоздает вашу базу данных в структуре классов. Это известно как анемичная модель и считается анти-паттерном.

Модель анемичной области - это анти-паттерн. «Модель на таблицу», как предполагает Венема, может рассматриваться как «воссоздание вашей базы данных», однако совершенно неверно говорить, что это одна модель анемичной области.

От Мартина Фаулера:

Основной симптом анемичной доменной модели состоит в том, что на первый взгляд она выглядит как настоящая вещь. В доменном пространстве есть объекты, многие из которых названы в честь имен существительных, и эти объекты связаны с богатыми отношениями и структурой, которые имеют истинные доменные модели. Уловка возникает, когда вы смотрите на поведение, и вы понимаете, что на этих объектах почти нет поведения, что делает их чуть более мешками добытчиков и сеттеров.

(акцент, мой)

Ключевым фактором в модели анемичной области является отсутствие поведения или методов в классах модели домена.

Это потому, что классы должны иметь как данные, так и поведение. Если вы ограничиваете свои модели одной таблицей, куда вы помещаете код (поведение), который должен иметь дело с данными и поведением из нескольких таблиц?

Опять же, вы можете и должны поместить поведение в свои доменные модели, даже если они отображаются только на одну таблицу. Поведение, которое влияет на несколько таблиц, действительно влияет на несколько объектов, которые отображаются на несколько таблиц. Доменно-управляемый дизайн - это подход к точно такой же проблеме, о которой говорила Венема: «куда вы помещаете код (поведение), который должен работать с данными и поведением из нескольких таблиц?»

И ответ - Совокупный Корень . Мартин Фаулер заявляет:

Агрегат - это шаблон в дизайне, управляемом доменом. Агрегат DDD - это кластер доменных объектов, которые можно рассматривать как единое целое. Примером может быть заказ и его отдельные позиции, это будут отдельные объекты, но полезно рассматривать заказ (вместе с его отдельными позициями) как один агрегат.

(акцент, мой)

«Кластер доменных объектов» также можно рассматривать как «доменные модели, которые отображаются на несколько таблиц». Поведение, которое влияет на несколько таблиц, должно быть определено в Aggregate Root - класс, который инкапсулирует «вещь», которая влияет на несколько таблиц или объектов:

Опять от Мартина Фаулера:

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

Чтобы ответить на оригинальный вопрос ОП:

... будет ли создание модели для таблицы базы данных хорошей практикой? Таким образом, методы не пишутся дважды.

Я бы сказал, что это хорошее место для начала, но помните, что ваша схема и объектная модель не должны соответствовать 100%. Объектная модель должна быть больше заинтересована в реализации и применении бизнес-правил. Схема должна быть больше ориентирована на хранение бизнес-данных в модульном и масштабируемом виде.

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