Модели с несколькими таблицами с MVC?

Question

Я только начинаю работать с MVC, и, похоже, это будет отличный способ, как только я смогу переключиться на это.

Большая часть материала, с которым я сталкивался, кажется, имеет отношение 1-1 между моделями, представлениями и таблицами - то есть каждая модель представляет таблицу и допускает CRUD, плюс более сложные функции.

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

Я бы хотел использовать представление / signup и контроллер для создания () учетной записи, но хотел бы использовать представление / members / account и контроллер для обновления, изменения pw и т. Д.

Было бы лучше иметь модель регистрации, или я согласен с тем, что использую нужную модель из нескольких мест?

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

Я использую PHP с CodeIgniter

Answer 1

В целом, то, что вы хотите сделать, скорее всего, будет считать ваши таблицы дополнительным «слоем» под вашей моделью; концепция MVC обычно не слишком связана с реализацией проблем поддержки; то есть, используете ли вы таблицы БД или хранилище плоских файлов или представления данных в памяти.

То, что я хотел бы предложить, - это рассмотреть проблему как проблему наличия одного уровня, который взаимодействует между вашими таблицами и вашим приложением; ваш слой «объекты данных». Думайте об этом как о чистой сериализации. Если вы используете объектную модель, это будет ваш слой ORM.

Тогда вы хотите иметь еще один слой, который определяет «бизнес-логику»; то есть взаимодействие ваших данных с вашими данными. Это связано с такими вещами, как взаимодействие учетной записи с пользователем и т. Д. Инкапсуляция здесь, в основном, обеспечивает взаимодействие на высоком уровне. Таким образом, вы можете определить абстракции, наиболее подходящие для ваших бизнес-требований, без необходимости зависеть от реализации; например, вы можете определить модель «UserAccount», которая будет делать все, что вам нужно для обработки учетных записей пользователей; определить все, что вы хотите, чтобы эта абстракция. Затем, когда у вас есть эта абстракция, это ваша Модель; Затем вы можете определить, во внутренней работе этой модели, как происходит взаимодействие с вашим персистентным кодом.

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