Процедурный фреймворк

[alexandr.coder]

Процедурный фреймворк - хорошяя идея? По идее чисто процедурным он не будет. Классы всеравно будут. Например, модули.

[s0rr0w]

Процедурный фреймворк - хорошяя идея? По идее чисто процедурным он не будет. Классы всеравно будут. Например, модули.

Все зависит от конкретной реализации

[LunatiK]

Процедурный фреймворк - хорошяя идея? По идее чисто процедурным он не будет. Классы всеравно будут. Например, модули.

Голосовать не стал, согласен с s0rr0w, вопрос не ясен, какие цели ? что именно он будет из себя представлять ? какая у него специализация ?

[rus]

ну, если проект небольшой, то почему бы и нет?

[stars]

Процедурный фреймворк - хорошяя идея? По идее чисто процедурным он не будет. Классы всеравно будут. Например, модули.

Хороша ли идея текстовых файлов, да! Все ли текстовые файлы хороши, нет!

[rus]

Все ли текстовые файлы хороши, нет!

Они еще и разными бывают?

[stars]

Они еще и разными бывают?

Несомненно... тут мысль немного более глубокая, смотри шире...

Edited September 22, 2010 by stars

[rus]

смотри шире...

объясняй глубже

[LunatiK]

объясняй глубже

Дело не в файлах, а во внутренней структуре данных ну и уместности их использования в разных ситуациях.

[stars]

объясняй глубже

Ну пожалуйста:

Те́кстовый файл — компьютерный файл, содержащий текстовые данные, как правило, организованные в виде строк.

Так как содержание текстовых файлов может быть различным(как в содержащимся тексте, так и в "смысле", бывает случай когда текст разный но смысл один), отсюда и вытекает, что (Все ли текстовые файлы хороши, нет!)

Однако словосочетании "текстовые файлы" можно заменить на другое, допустим на "Процедурные фреймворки" потому что суть в том что топик стартер просит оценить кота в мешке...

Edited September 22, 2010 by stars

[alexandr.coder]

Голосовать не стал, согласен с s0rr0w, вопрос не ясен, какие цели ? что именно он будет из себя представлять ? какая у него специализация ?

MVC структура: Есть папка application в которой находятся ещё три папки, которые соответствуют всем трем элементам патерна: Controller, model,views.

В папке контроллеров есть ещё папки - аналоги контроллера. В тех папках файлы - аналоги методов. И допустим в каждом "контроллере" есть некий файл, который вызывается если вызван этот "контроллер" - если короче аналог конструктора.В моделях так же само. Вьюверы без пояснений - и в обычных фреймворках там просто файлы. И тоже с неограниченой вложеностью. Есть какие-то пользовательские функции, которые отвечают за системные процессы - загрузить вьювер, подключить библиотеку и т.д. А сами библиотеки или пакеты - классы.

Фреймворк должен быть расщитан на работу с 30-50к пользователей + неограниченно гостей.

Мне бы хотелость узнать хороша ли эта идея. Что в ней хуже\лучше по сравнению с ООП фреймворком.

[LunatiK]

Навряд ли эту идею можно назвать «хорошей», не вижу смысла использования процедурного подхода к такой сложной и разветвлённой структуре. Если вы думаете что выиграете в производительности, это вероятно, но тоже сомнительно. ООП в этом случае сократит расходы и нервы в будущем, а возможно и в настоящем. тем более что собираетесь использовать классы в качестве отдельных модулей, Лучше не мешать.

[rus]

mvc лишь разделяет логику от представления, но представьте себе что у вас в одном файле будет 50 000 строк кода!

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

[alexandr.coder]

Лучше отказаться от этой идеи и продолжать делать ООП фреймворк?

[rus]

Лучше отказаться от этой идеи и продолжать делать ООП фреймворк?

в этом случае нужно совместить oop и mvc и разбить на отдельные файлы

[LunatiK]

Лучше отказаться от этой идеи и продолжать делать ООП фреймворк?

Если вы не можете доказать целесообразность использования процедурного подхода к данной ситуации не можете: минимум для себя, максимум для нас, то зачем? плюсы ООП всем извесны, плюсы поцедурного подхода вроде как тоже - взвешивайте!

[alexandr.coder]

Тогда какой ООП фреймворк на php5 можете посоветовать.

[Int]

Если вы не можете доказать целесообразность использования процедурного подхода

А где презумпция невиновности? Это ООП должен доказывать, что он нужен, а не наоборот

[LunatiK]

А где презумпция невиновности? Это ООП должен доказывать, что он нужен, а не наоборот

Это она и есть, вы просто не стой стороны посмотрели

[alexandr.coder]

Какой ООП фреймворк на php5 можете посоветовать. Думаю что надо что-то поделать на существующем фреймворке, прежде чем делать свой.

[Vlad]

Какой ООП фреймворк на php5 можете посоветовать. Думаю что надо что-то поделать на существующем фреймворке, прежде чем делать свой.

Yii, Cohana

[dandandan]

2 года писал с помощью процедур. Год назад перешел на ООП. Сейчас все новые проекты пишу на ООП, Ощущения - что процедурный стиль хуже... Все старые проекты реализую в процедурах. Особой сложности перестраиваться между первым и вторым не вижу. Так что на мой взгляд возможно и ООП и процедурный фреймворк.