Asbo

чтобы в редакторе кода, когда вы набираете
$object->|
он мог вам подсказать какие свойства есть у объекта.

чтобы явно указать видимость свойств (например, протектед)
чтобы потом не искать какие свойства есть у объекта через год, шарясь по всем его методам.
чтобы у вас не отвалилось все к чертям, если вы перепишите конструктор в классе-потомке.

На вопрос невозможно дать однозначный ответ.
Если сильно постараться, то на любом языке и стеке можно сделать почти все что взбредет в голову, это уже зависит от склонности человека к извращениям. Более адекватным подходом является подбор инструментов отталкиваясь от задач. Задачу вы не озвучили, поэтому посоветовать что-то по существу не видится возможным.

Ты веcь такой кругом молодец, то знаешь, это знаешь. А теперь представь себе среднестатистический проект, который должен приносить бизнесу деньги. За две недели работы ты едва напишешь хлипкий CRUD для данных, неправильно смаппив бизнес-сущности в объекты ORM, ещё через месяц натянешь какой-то слайдер на jQ, попутно захватив 2мб JS кривых библиотек, а через два заказчик поставит тебе плохую оценку, потому что твой ценник он оплатил не за то, что ему нужно, а потому что ты знаешь монады, которые ему даром не сдались.

А теперь давай представим простого программиста. Из алгоритмов он с трудом вспоминает сортировку пузырьком, а двусвязный список — предел его знаний о структурах данных, и даже этим списком он пользовался два раза в жизни. Хаскель он никогда не видел в глаза, C++ учил только в школе, вместо этого пишет неэффективный код на PHP. И у него есть опыт. За день он распишет сущности, за второй сделает универсальный CRUD, на третий день поднимет фронт на React'е с SSR. Да, внутренности проекта будут "медленными". Вместо O(logN) что-то будет выполняться за O(N) или даже O(N^2), но всем похер. Пока всё работает на приемлемом уровне — бизнес радуется.

Кстати, к чему эта поучительная лапша? Я хотел сказать, что всеми этими модными словами можно пугать друзей и преподавателей, но в реальной жизни все алгоритмы уже реализованы, все типы данных уже подобраны оптимально. Знать их полезно для себя (чтобы мозг не атрофировался), но не для работы. Для работы тебе нужны такие навыки как:

* Оптимальный баланс между говнокодом и идеальным кодом
* Оптимальный баланс между скоростью разработки и оптимизацией кода
* Оптимальный баланс между поддерживаемым кодом и костылями
* Умение использовать те инструменты, с которыми ты работаешь. Опять же, для того, чтобы писать быстро, при этом имея минимальное количество говнокода и обеспечивая максимальную поддерживаемость (в пределах сроков). Например, можешь выкинуть в помойку свой Vim, как бы круто ты себя не чувствовал, разрабатывая в консольном редакторе, если продукты от JetBrains позволят за это же время сделать что-то лучше или чего-то больше
* Чувство "знаю больше менеджеров". Это то чувство, когда тебе кажется, что "вот эта фича скоро изменится" и надо сделать архитектуру заранее более гибкой. Или "вот эту фичу мы через месяц выпилим" и не надо тратить на неё силы — напиши костыль и через месяц с чистой совестью удали его
* Знания, как сделать ту или иную фичу. Потому что фичи повторяются (немного видоизменяясь) от проекта к проекту. И если ты сделал что-то за два дня, в следующий раз ты похожее сделаешь за три часа

Что касается инструментов, выбери любой полноценный фреймворк, который умеет решать 90%+ потребностей "из коробки": Symfony, Django, Laravel

Всякие "минималистичные" поделия вроде Falcon, Flask (в PHP не знаю, я на питоне пишу) оставь хипстерам. Пусть они говорят: "Мой фалкон такой быстрый, он написан на Cython". Тебя это не должно волновать, потому что бизнес с твоей скоростью разработки уже заработал достаточно денег, чтобы купить ещё десять серверов, пока фалконисты неделю гуглили, как прикрутить миграциии и запустить юнит-тесты на VPSке за пять баксов.

https://www.php.net/manual/en/refs.database.php

Vendor Specific Database Extensions
CUBRID
DB++
dBase
filePro
Firebird/InterBase
FrontBase
IBM DB2 — IBM DB2, Cloudscape and Apache Derby
Informix
Ingres — Ingres DBMS, EDBC, and Enterprise Access Gateways
MaxDB
Mongo — MongoDB driver (legacy)
MongoDB — MongoDB driver
mSQL
Mssql — Microsoft SQL Server
MySQL — MySQL Drivers and Plugins
OCI8 — Oracle OCI8
Paradox — Paradox File Access
PostgreSQL
SQLite
SQLite3
SQLSRV — Microsoft SQL Server Driver for PHP
Sybase
tokyo_tyrant

Учитывая, что там всё построено на ООП, а не на процедурном подходе, то ответ очевиден - нет.

Так. Ну давайте начнем с MVC, идея которого, разграничивать три функции веб-приложения и делать их заменяемыми. Это значит, что если у вас, например, база была на MSSQL, а стала на MySQL или еще куда переехала, то вам не нужно будет вносить изменения в V и C (при условии, что представление и контроллер действительно не зависят от модели)
Представление V может быть как заменяемым так и отсутствовать вовсе
Razor - это, конечно, интересно, но, честно говоря, в промышленной разработке встретить его довольно сложно
Зато есть уйма проектов на ASP.NET + Angular/Vue/Backbone
Все они работают на идее, что сервер возвращает данные в чистом виде (JSON или XML), а за представление отвечает какой-нибудь веб
Можно смело говорить, что большинство современных веб-проектов выбирают именно подход API + Web. Плюс еще и в том, что т.к. сервер отдает только данные (без разметки), очень легко добавить в проект и мобильное приложение - оно принимает те же данные, но работает с ними по-своему. А, может, ваш API будет использоваться другой системой? Так опять же - данные в чситом виде и не надо будет парсить html

Поэтому:

Действительно ли есть такая практика обходиться без Razor при компонентном подходе вместо монолитного?

Да. И она более предпочтительна

Неужели рентабельно все вытаскивать аяксом через API?

Стоит, т.к. получая данные в "чистом" виде, frontend-разработчики чувствуют себя свободнее в работе с мордой. Ну и плюс, возможность подключить мобилку

И как тогда делается морда проекта?

Все, что вам нравится во фронтэнде (Фреймворки, либы, шаблонизаторы или же просто чистые html, css, js)

А если, например, нужно title или description на страницах для поисковиков, они же должны быть сразу в теле страницы, а не получаться через ajax?

ну ангуляр, например, как-то индексируется гуглом (ну еще бы он не индексировался). На эту тему стоит почитать статьи

Верстаются файлы типа index.html, в него подключаются css и javascript?

Ну и самое главное, если такое практикуется, то может есть пример на github?

Да. Ищите репозитории/книги/видео по словам ASP.NET + Angular - искать будете недолго