Тема создана конструктивного холивара для ))
Задумываюсь над достаточно крупным проектом.
Не знаю как и на чём это всё написать.

Здесь история одного проекта сходного с сабжевым, который я реализовал.
Можно не читать. ))
Один раз уже писал достаточно сложную CMS для сайта-каталога с уникальной админкой, т.е. не только работа с контентом, но и статистика, установка цены, модерация всего и вся, фильтры товаров, рейтинги, отзывы, с личными кабинетами клиентов, с системой платежей, тарифами и ещё тонна плюшек.
Писал на том на чём знал, т.е. на обычном функциональном PHP. Где знаний хватало, использовал сторонние классы. На выходе получилось шустрая система, но быдлокода местами в ней было OVER9000 ))) (особенно в реализациях AJAX).
Хотя с файловой структурой разобрался даже заказчик и верстальщик далёкие от PHP.
В этой папке шаблоны, в этой системный конфиг и дрова для БД, в этой загружаемый контент,
парсер (роутер) выглядит так и так, на сайте 3 точки входа: Сайт, Админка и кабинеты клиентов и т.д. И на выходе получился не ООПшный MVC, т.е. велосипед.
Фактически я на этом проекте учился. Даже пытался реализовать некое подобие TDD. Самое нудное и долгое - было написание админки, т.к. вся CRUD реализация админки имела отдельные функции и/или файлы. Наследование кода стремилось к 0. Зато были и плюсы в этом. Быстро что-то где-то подправить (т.к. заказчик засыпал меня идеями и изменениями ТЗ по ходу выполнения) было очень просто и действительно быстро. Но вот поправить что-то серьёзное - начинался тестинг всего с нуля и полный брэйнфак с отлавливанием багов, которых до изменения не было. Например без использования ORM работа с БД была почти моментальная, но если менялась структура таблицы, все запросы связанные с ней приходилось править/просматривать. Потом долгие запросы логировались и переписывались или часть логики из запроса переходило в PHP.
По большому счёту меня всё в этом устраивало, кроме того, что достаточно сложно из этого всего скомпоновать некую CMS "из коробки" или хотя бы взять >50% кода в другой проект. GUI админки не в счёт. Ну и наверное всё-таки скорость разработки и конечно сложную масштабируемость (но возможную) на выходе.
// История закончилась

Теперь я в раздумьях. Проект, которым я хочу заняться - очень похож на тот. Но это уже мой личный, т.е. писать я его буду один и сопровождать код в дальнейшем сам. Если даже не сам, то всё в нём объяснить могу. Так как это не выгоды для а хобби ради, то времени на проект у меня тонна (но хотя бы до выхода PHP6 доделать ))).

Конечно я хочу учесть все ошибки предыдущего проекта и не повторять их в этом.
Хочу спросить у Вас. Как бы и на чём бы Вы реализовывали проект? Если проект подразумевает одного разраба, вы бы использовали Symfony+Doctrine+Twig или писали свою ООП/ФП систему с нуля, или что-то третье? Symfony+Doctrine+Twig это панацея от многочасовых отлавливаний багов, трудностями с реализацией AJAX, нудного писание CRUD функций? Проще ли с этим набором менять структуру БД, или это только усложнит? Выши мнения? Я попробовал этого зверя на примере сайта блога и визитки + админка. Моё мнение, что на таком мелком варианте оно только всё усложняет, но возможно на большом проекте…? Эту связку я взял для примера + потому что она идёт в комплекте. Возмно другой вариант Framework’ов?
Повторюсь, что проект - не новостной портал, не блог и не сайт одного продукта. Здесь очень много бизнес-логики как в социальных сетях + витрина разношерстного товара как на amazon + работа с клиентами через личные кабинеты со всеми плюшками вроде моментальных фидбэков, кучей AJAX и POST т.е. полноценного клиент-сервер web-приложения а-ля личный кабинет хостера или провайдера.
Буду рад любым Вашим доводам исходя из Вашего огромного опыта. Спасибо.

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


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

ИМХО пишите сразу всё на ООП

Panoptik
Спасибо за ответ.
Писать на ООП. +1)

Я постепенно отхожу от процедурного (функционального) стиля в пользу ООП, но даётся сложно. Чужие классы на примере или хотя бы с описанием класса внедрять легко. Поэтому Framework. Писать что-то своё на ООП - иногда хочется плюнуть и быстро написать процедурный костыль, чем стараться красиво на ООПэшить )))

Framework или полностью своё ООП?

Изменять структуру надо всегда, в Doctrine при этом надо менять (не помню как правильно называется) манифест кажется, т.е. описание БД, хотя если оно из манифеста создаёт таблицу, которая нужна ему, а не мне, то может это и проще, но как-то у меня более классический подход к БД. Сначала разрабатываешь архитектуру, потом структуру, связи, загоняешь это всё через например PHPMyAdmin, а потом работаешь сразу и везде: смотришь как ведёт себя таблица, как скрипт и что на выходе. Учить как Doctrine работает, отказаться от классического подхода в пользу абстрагированного, наступать на грабли... Оно того стоит? (Работаю Web-программистом - PHP,MySQL,Ajax,Jquery,CSS,XHTML,XML - всего понемногу) Конечно хочется работать и зарабатывать нормально на чём-то одном. Отсюда второй вопрос. Оно надо для карьеры (ORM)?

А что на т этом свет клином сошелся.


тогда однозначно никаких навороченных фреймворков - все время уйдет чтобы в них бизнес логику впихнуть.
Чтобы не совсем с нуля - лучше использовать простые и понятные решения которые не определяют архитектуру (например для работы с БД я обычно использую ADODB)
То есть отдельные самодостаточные библиотеки котрые упрощают работу в нужном месте но не путаются под ногами где их не надо.

Нет. Просто это первый Framework в который я погрузился с головой из-за хорошей документации к нему. С codeigniter, kohana и Yii я не очень сдружился, может просто не хотел тогда смотреть в сторону фреймворков, а когда посмотрел, то лучше Symfony не нашел. ) Может стоит пересмотреть своё отношение к ним?

Симфони слишкомм мудреный. Самая лучшая документация и русскоязычное комюнити в CI. Это самый простой фреймворк. Я его юзаю когда в проекте никаких фреймворков нафиг не надо но заказчику хочется именно фреймворка.
YII вобщем то тоже не плох.

Но вообще надо смотреть по реальному проекту. Многие фичи потом сложно реализовывать именно потому что вместо простого вызова PHP скрипта приходится городить кучу каких то контролеров и прочей фигни. То же самое с дизайном и шаблонами.

caballero
То есть если я правильно понял, нафиг Фрэймворки, пользуйся сторонними классами чтоб не городить свой велосипед (PHPExcel или FPDF например или ADODB =)), а так пиши под каждую задачу свой класс и т.д.

То есть если сравнивать JS форки, CSS форки и PHP форки, то понятно что без JQuery обойтись сложно, нудно и долго, CSS форки нафиг никому не нужны (кто-то их вообще юзает?) а вот как дела с PHP??? Есть тонны форков, ORM и пр., и к каждому тонна документации, комьюнити и т.д. Для повседневных сайтов форки - то что нужно, для сложных/уникальных нужно/лучше всё самому? так?

Неправильно понял
Во первых фреймворки и есть сторонние классы. А во вторых зависит от задачи. Если задача типовая то класс пригодится в нескольких местах а возможно и найдется готовый.
Например - отправка почты. Можно конечно наваять свое и юзать его во всех проектах. А можно взять например PHPMailer.
Если задача не типовая то никакой фреймворк не поможет - все равно придется все писать самому. И вот тут вопрос - время которое ты потеряешь запихивая реализацию в фреймворк будет больше чем время которое сэкономишь на применении фреймворка для другого функционала ( навигация по страницам, ЧПУ и прочее) или меньше.
В чем удобство использования отдельных заточеных под функционал библиотек. Они решают конкретную задачу (отправка почты, работа с БД и т.п.) а в остальном есть пространство для маневра при пректировании архитектуры. Фреймворк может иметь все в одном флаконе но сразу ставит тебя в рамки. Если твой функционал в эти рамки вписывается малой кровью - хорошо. А если нет - будет много гемора.
Поэтому на форумах куча вопросов типа - вот у меня таколй то фреймворк/CMS как мне сделать тот-то.
В обычном PHP человек просто бы сел и сделал а так ему приходится разбиратся а как же воткнуть требуемое в фреймворк, где найти это место что поменять да так чтобы не вылезли косяки где в другом месте.

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