Не вижу смысла так извращаться. Где то была тема про неудобства названий в множественном числе в программировании, всё таки это не литературный язык.
Считай что название это имя, а не описание. cache, user, log, config вместо caches, users, logs, configs

_____________
Промокод предоставляет скидку на заказ домена и/или хостинга reg.ru
BFCC-3895-8804-9ED2

user ещё лаконичней, на целую букву)

Дело привычки, всем и так понятно что в таблице может быть несколько записей, а "user" это как отражение типа данных в этой таблице. Это как использовать слово "блокнот" вместо "заметки", заметки в блокноте, "config" вместо "settings", настройки конфигурации.
То есть это таблица user, в которой лежат users and their ip and their photo.

В общем я бы не наворачивал кода ради сомнительной "понятливости". Делать склонения имён программных сущностей что бы потом что? Что бы как стихотворение читать?) Сам же учил древнеиндейскому ритуалу.

Да и потом с этими склонениями можно загнаться сильно:
Право доступа под названием user.edit, которое разрешает редактировать пользователей, но оно разрешает редактировать не конкретного, а всех, тогда надо назвать users.edit, да и редактировать можно не один раз.
Директория template хранит шаблон сайта, но он состоит из минишаблонов, всяких там blog.tpl, message.tpl, тогда это уже набор шаблонов (templates), получается фраза "скачай и поставь шаблон" неправильная.
В итоге приходишь к тому что "всё множественное". В директории несколько файлов, базе данных несколько баз, в классе несколько свойств/методов, в переменной несколько символов/слов/предложений)

_____________
Промокод предоставляет скидку на заказ домена и/или хостинга reg.ru
BFCC-3895-8804-9ED2

Так а в чем проблемма то?
Основные критерии патерна

• каждый экземпляр данного класса соответствует одной записи таблицы;
• при создании нового экземпляра класса (и заполнении соответствующих полей) в таблицу добавляется новая запись;
• при чтении полей объекта считываются соответствующие значения записи таблицы баз данных;
• при изменении (удалении) какого-либо объекта изменяется (удаляется) соответствующая ему запись.

class Users {
  private __construct() {}
  public static createUser() {
    return new self;
   }
}

$user = Users::createUser();
$user->setName("vasja");
$user->save();
$user->update()
$user->delete();

$user = Users::findById(123);
...

_____________
[продано копирайтерам]

в народе - принято говорить не объект, а модель

эту чепушию каждый сам для себя распишет, достаточно работать с свойствами модели

$model = (yii::$app->request->post('id')) ? Model::findOne(['id' => $id]) : new Model;

$model->name = 'Ivan';
$model->age = 24;

if($model->save()){
   ....
}

к тому же в Yii есть load в модель - можно просто ассоц. массив передать

$data[
 'Model' => [
    'name' => 'Ivan',
    'age' => 24
  ]
];

if($model->load($data) && $model->validate()){
    $model->save();
}

миграции так же можешь перенять в свой фреймворк.

_____________
HTML, CSS (Bootstrap), JS(JQuery, ExtJS), PHP, MySQL, MSSql, Posgres, (TSql, BI OLAP, MDX), Mongo, Git, SVN, CodeIgnater, Symfony, Yii 2, JiRA, Redmine, Bitbucket, Composer, Rabbit MQ, Amazon (SQS, S3, Transcribe), Docker

Не будем плодить холивар по-поводу необходимости геттеров и сеттеров.
Просто, что случиться, если написать (с точки зрения php все законно!)
$model->age = "Столько не живут";

А в базе поле age на секундочку int8

_____________
[продано копирайтерам]

Не будем. Дело в том, что в AR свойства, это название полей таблицы. И тут это вообще не критично. Сеттеры тут просто излишни. И обычно ими не пользуются.

Если понадобятся другие свойства, то нужно думать. А вообще я сам толком не понял, для чего Игорь это написал.

_____________
Если вам недостаточно собственных заблуждений, можно расширить их мнениями экспертов.

Нужно уважать мнение оппонета. Ведь заблуждаться - его святое право.

Настаивал, настаиваю и буду настаивать на своем. На кедровых орешках.

Я для коллекций обычно использую слово list, которое явно указывает что там список.
Например в том же классе User будет метод User->get(1), а если нужно получить всех пользователей тогда User->getList(), как тут быть с буквой s? Делать другой класс Users->get() или методу добавлять s User->gets();? Ну что бы читалось)
Тоже самое с переменными, есть $user, есть $userList. По мне "легкочтение" заключается в том, что бы сразу броситься в глаза, $user|$userList этом плане более легко заметнее чем $user|$users.
И сразу понятно от куда эта переменная пришла $userList = User->getList().

На практике такого нет мне кажется. Есть что то вроде "select id from user where...", ИМХО это проще читается, чем дополнительно изворачивать язык произнося s

Ну и если пофилософствовать, то таблица это сущность, с которой можно производить какие то действия, удалить там или переименовать. Она как ящик, как коробка, со своим названием, со своей структурой. Таблица это "она", ну или "он", если рассматривать как контейнер. А мы называем её/его "они" - users, как будто их много. Но она одна, значит users это не имя таблицы, это её описание, это то что она хранит, получается сама таблица безымянная. А хранить она может много всякого, тогда надо в описании перечислять что она хранит. То есть допустим таблица links, хранит не только ссылки, но и их названия и дату создания, в таком случае её надо описывать так links_and_their_description_and_their_creation_time.
ИМХО лаконичнее дать ей имя вместо описания, назвать её link, тогда и класс будет Link, и переменная $link = Link->get(1)

_____________
Промокод предоставляет скидку на заказ домена и/или хостинга reg.ru
BFCC-3895-8804-9ED2

Что именно уныло, AR или миграции? Не припоминаю, если честно, хотя теоретически могло быть, мне ближе Doctrine2. Миграции штука классная, сохранение состояния структуры БД в репозитории.

twin, а ты меня с какой целью в топик приглашаешь?