Несколько моделей таблиц с MVC?

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

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

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

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