Я не пихал, и Вы не пихали и никто не пихал. Зачем?
Я в принципе не вижу смысла переносить рабочий проект с одного фреймворка на другой. Да и никто этим не будет заниматься. И вообще мне кажется глупой идей подключать сторонние библиотеки из других фреймворков/движков в не родную среду, поэтому довод, что Ваш класс можно адаптировать под другое ядро не совсем корректен.
А разве в чужой монастырь со своим уставом можно?

_____________
Заработок для веб-разработчиков: CodeCanyon
Мое Портфолио

Так это мне в упрек ставят же... Я тоже не собираюсь этого делать. Адаптировать да, всегда пожалуйста. А там как в мультике "Лучше один день потерять, потом за 5 минут долететь". А противники мне крылья режут своими доводами про скрорсть разработки и унификацию Не дают летать... Ползать надо говорят, ибо нефиг. Все ползают и ты ползай)))

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

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

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

ДА КОНЕЧНО!!! Именно в этом вся прелесть и заключается. Зачем же писать 100 раз тоже самое, если оно уже имеется?
Рассмотрим преимущества:
1) Если имеется и протестировано, то оно будет и в других местах работать
2) Если немного не подходит, то можно подправить при помощи extends или замены внутренних компонентов и наслаждаться тем, что тестировать надо только этот участок.
3) Если имеется описание типа БД , то можно работать не вникая в то, какая разновидность этого класс используется. Нам становится все ровно применяет ли он внутри mysql или mysqli или просто Mok. Это единственный способ по человечески раскидать большое задание на нескольких программистов или просто заниматься какой то задачей изолированно от других проблем.

Рассмотрим недостатки:
1) Если класс не грамотно продуман, я имею в виду не качество его внутреннего кода, а принцип его применения, то эти недостатки будут видны во всех местах использования. Если учесть что этот недостаток также может возникнуть и в линейном программировании, то нас не должно это останавливать применять класс БД во многих проектах.

Иногда при новых проектах ты понимаеш то, что твоя архитектура может быть конкретно улучшена, или старая конкретно устарела. В этом случае имеет смысл подумать о новом начале. В противном случае нет не какого оправдания для программирования уже написанного кода.

Дизайнеру этот скрипт не поможет, но было бы неправильно рассматривать View только как попытку отделения html от php. View это попытка отделить Оutput Логику от основного скрипта, и в примере с $excelObj это принцип на 100% исполнен. Мало того я могу себе представить, что инстанц этой View может быть заменен и при вызове тех же методов он будет выдавать вместо ехел к примеру хтмл или pdf.

_____________
↓↓↓↓↓↓↓↓↓↓
ответ может быть здесь
или в mysql_error();

Почему это. Кто мешает сделать тоже самое в моей структуре? Располагай выше корня систему, прописывай пути в конфиге и в путь. Если нужен однотипный функционал. На нашем проекте так и сделано, и ничего, работает. Не вижу принципиальной разницы...

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

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

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

Тоже не пойму. Я имел ввиду разные проекты. Не везде можно применить свой класс БД. А если такая возможность имеется, то в чем принципиальное отличие? и я лучше напишу 3 версии под разные носители, чем одну универсальную. Преимущество у класса разовое, в момент разработки, а код будет работать годами.

Так все-таки нечего делать дизайнеру в классе? Чем меня тогда упрекают? Логику я вполне спокойно могу разделить и без этих веревок. Ровно как и заменить весь модуль на вывод PDF.

Вы чего так панически боитесь, призывая к унификации? Код бывает двух видов. Уникальный, который по определению не может повториться в рамках одного проекта. Тогда унификация прямо вредна, ибо ведет к раздуванию и усложнению.

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

Разговоры о том, что можно поменять в одном месте запрос к примеру и он изменится везде - несостоятельны. Ибо многоразовый код пишется как раз централизованно, как мой пример с консультацией. Меняешь что-либо в модели и на всех страницах, где она используется, все меняется. Другой вопрос, когда это вообще общий класс. Скажем User. Так вот, изменив что-то в нем, можно получить нежелательный эфект там, где этого изменения не ждали. Потому и делаются абстрактные модели и переопределяются методы в наследниках. Я просто не понимаю профита, зачем делать общий базовый класс, если все равно в наследниках мы пишем свою реализацию. Зачем эта шапка Мономаха? Что бы собрать воедино разные кусочки функционала. Это как у Попова.

Не проще ли не создавать, если пусто? И не проще ли не соединять, если до этого не делить?

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

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

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

Вот для этого и нужны классы, вместо прямого взаимодействия с API

Верно именно так.
Визуально привык , кому как удобно.
Я не останавливался на этом, можно и autoloader и без namespace.

П.С
Вы же прекрасно понимаете, если бы нужно было создать framework,
нужно проектировать его,
а это не 1-2 дня.

Раньше была

MSSQL_QUERY, MSSQL_FETCH_ARRAY 

( библиотека mssql.dll )
microsoft от этого отказалась, и в php 5.3.x , не стала поддерживать.
Внесала свою sqlsrv_.

Всё на новый сервер нельзя уже перейти, изменить это недели тратить пришлось..
Тоже вот так вот люди думали, о нет, нечего не измениться.
http://www.microsoft.com/en-us/download/de...s.aspx?id=20098

Да знаем:
Вот тебе пример:

Наша структура

PHPFORUM

• -RU
• -Manager
• -Helper

<?php
namespace PHPFORUM\RU

use PHPFORUM\Manager;
use PHPFORUM\Helper;


$questionManager = new Manager\Question();

$questionHelper = new Helper\Question();

При это структуре сразу понятно, кто что использует и откуда.