По хорошему, твой код ничего не должен знать о том, как и где хранятся данные, и как их от туда доставать. Вся эта магия должна быть заключена в 1 месте - в репозиториях. Репозиторий это по сути фасад над хранилищем данных, который предоставляет простой и удобный интерфейс для доступа к данным.
Он не должен знать, но он должен отправлять их на хранение к примеру когда новый клиент зарегистрировался вся validation делается на уровне приложения, но потом то приложение должно дать команду сохранить эти данные, пускай оно не знает как это будет осуществленно дальше, но команда исходит от преложения.
Обьяект $databaseObj это простенький wrapper для базы данных MySQL в котором есть generic метод add_record(string $table, array $fields) {...} который данные и добавит в указанную таблицу и даст return true;
1. Можно ли считать generic wrapper $databaseObj полноценным Data Storage Layer или он должен быть чем то большим чтобы так называться?
2А. Приложение знает название таблицы table_users где хоранятся данные, это нарушает правило что оно не должно знать где данные храняться и как?
Если бы я название таблицы перенес из приложения просто бы команду $storage_layer_obj->add_new_user($user_fields_arr); то мне бы пришлось действительно создавать сложный Data Storage Layer с кучей кода какой в этом смысл?
2Б. Я могу подключить одновременно воторую базу если у меня есть этот отдельный слой и просто дать её в другом обьекте и все не надо менять код приложения это плюс.
Но знание приложением название таблицы чему мешает? Ведь допустим я преешел с MySQL на другой движок все равно в любой базе нужно давать название таблице.
Есть еще статья эта идея не нова ИМХО есть статья Multitier architecture на википедии об том же самом, только вот одно но такое деление это будет соответствовать принципам ООП?
Как это реализовать, а именно разбить на Application и Domain слои есть какие-то примеры?
И зачем нужно Data Storage Layer понятно чтобы можно было легко поменять базу данных, но можно же сделать Wrapper зачем целый отдельный механизм заталкивания в базу какой в этом смысл?
находите вакансии и их требования, и начинаете себя подтягивать.
Да там тоже ничего толко мне пишут скажут что-то вроде "Должен знать MVC и все современные способы и паттерны ОО програмирования" или требуют универсального солдато который будет знать все бак энд фронт энд потом еще локальные сети и прочее не относящееся к програмированию, я ищу работу чисто програмиста бак энд и баз данных, никаким верстальщиком и дизайнером фронт энда принципиально работать не хочу хоть раньше я этим и занимался много лет HTML CSS JS Photoshop теперь хочу уйти от этого исключительно в програмирование.
Отдельный холивар: готовит ли контроллер все данные для представления или представление может самостоятельно дёргать модели для получения интересующих данных.
Ещё холивар современного веба - а где вообще находятся контроллер и представление, на сервере или на клиенте?
Много там холиваров, с этим mvc.
По мне представление это чисто для генерации страницы клиенту тимплат+данные из модели, ведь когда юзвер жмет на ссылку по теории должен контроллер принять не вид.
Как контроллер и представление может быть у клиента или о каком клиенте идет речь?
Мелкий пишет:
А кто сказал, что mvc это про ООП? Это в первую очередь концепция разделения ответственности. До жути размытая концепция.
И ещё удивительная вещь - для использования ООП нет необходимости в использовании классов, а с использованием классов можно продолжать писать в функциональном стиле. Ладно, это не для джуниора фокусы Закатив глазки Хотя я серьёзно.
Когда я был ярым фанатом процедурки и жег на костре всех кто пропагандировал ООП, то я как то читал что MVC невозможно сделать процедурно, хотя сейчас понимаю что был не прав, это просто структура приложения.
Вот это я лично видел у индусов в коде классы, а смысла ноль просто зашили процедурный код в классы и обозвали ООП. Но как можно писать ООП без классов я не особо догоняю?
Если как ты говориш видел оба способа (контроллер управляет видом + моделью или контроллер просто подает данные в модель, а модель дает в вид) применяются какой ты считаеш лучше?
Читал тут в исходных текстах на Smalltalk-80 изобретатили MVC пишут что контроллер управляет моделью и видом. По моему это не сильно отличается от подхода в обычной процедурке когда есть страницы users.php, new_user_register.php и т.д. и в каждой странице есть своя тимплата Smarty к примеру. Ну и дальше все как всегда php страница там бизнес логика, а в темплате логика репрезентации инфы которую php страница достала из базы.
Я вот в подходе MVC не вижу особой разницы если делать по контроллеру на каждую страницу сайта это чем-то отличается от процедурного подхода кроме перестановки слогаемых и обзыванием крутым словом MVC?
Куча статей в интернете и каждая по своему описывает MVC.
Как это понял я
1. Модель это логическая база приложения.
2. Вид это просто темплата
3. Контроллер - не совсем понял зачем он нужен, некоторые говорят чтобы управлять моделью и видом, другие говорят что он только собирает команды пользователя и отправляет в модель.
Еще вопросец сколько моделей и контроллеров должно быть всего один или несколько в каких случаях нужно создавать дополнительный?
Недавно начал изучать обьектно ориентированое програмирование, раньше несколько лет писал процедурно, вопрос что нужно знать об ООП чтобы получить работу младшего PHP програмиста.
Сейчас для себя выделил цель понять MVC архитектуру и научиться правильно использовать SOLID и GRASP принципы програмирования, достаточно ли этого как базы для получения работы или нужно знать что то еще об ОО?
Хочу обсудить все за и против в вопросе процедурный стиль против объектно ориентированного программирования.
Давайте сделаем конструктивно чтобы тему не закрылы за флейм и не будем делать такие комменты как "Если ты пишешь процедурный код то ты херовый програмист" или "<Какой то> крутой прогер или мой учитель програмирования в универе смеется над таким вопросом" - так доказываются догмы.
Пишите конкретно по пунктам почему процедурный стиль неприемлемен вами или чем ООП лчше процедурного лучше сразу с примером кода.
Лично я утверждаю что вопрос ООП vs Процедурный стиль это дело выбора каждого програмиста, конкретно что один лучше другово в разы нету ни у одного стиля.
Объектный подход к планированию, написанию программы с точки зрения обьектов, что самом по себе ни чем не лучше любово другово подхода.
Этот стиль стал популаярен во многом блогадаря рекламе и насажденю в сми теперь многие програмисты и работодатели (которые вобще не секут в програмировании) думают что это какой-то стандарт и те кто его не используют не профессионалы.
Ели кто то думает что я упал с дуба посмотрите на критику ООП на с википедии.
Было показано отсутствие значимой разницы в продуктивности разработки программного обеспечения между ООП и процедурным подходом[11].
Кристофер Дэйт указывает на невозможность сравнения ООП и других технологий во многом из-за отсутствия строгого и общепризнанного определения ООП[12].
Александр Степанов в одном из своих интервью указывал, что ООП «методологически неправильно» и что «…ООП практически такая же мистификация, как и искусственный интеллект…»[13].
Фредерик Брукс указывает, что наиболее сложной частью создания программного обеспечения является «…спецификация, дизайн и тестирование концептуальных конструкций, а отнюдь не работа по выражению этих концептуальных конструкций…». ООП (наряду с такими технологиями как искусственный интеллект, верификация программ, автоматическое программирование, графическое программирование, экспертные системы и др.), по его мнению, не является «серебряной пулей», которая могла бы на порядок величины снизить сложность разработки программных систем. Согласно Бруксу, «…ООП позволяет сократить только привнесённую сложность в выражение дизайна. Дизайн остаётся сложным по своей природе…»[14].
Эдсгер Дейкстра указывал: «…то, о чём общество в большинстве случаев просит — это змеиное масло. Естественно, „змеиное масло“ имеет очень впечатляющие названия, иначе будет очень трудно что-то продать: „Структурный анализ и Дизайн“, „Программная инженерия“, „Модели зрелости“, „Управляющие информационные системы“ (Management Information Systems), „Интегрированные среды поддержки проектов“, „Объектная ориентированность“, „Реинжиниринг бизнес-процессов“…»[15].
Никлаус Вирт считает, что ООП — не более чем тривиальная надстройка над структурным программированием, и преувеличение её значимости, выражающееся, в том числе, во включении в языки программирования всё новых модных «объектно-ориентированных» средств, вредит качеству разрабатываемого программного обеспечения.
Патрик Киллелиа в своей книге «Тюнинг веб-сервера» писал: «…ООП предоставляет вам множество способов замедлить работу ваших программ…».
Известная обзорная статья проблем современного ООП-программирования перечисляет некоторые типичные проблемы ООП[16][неавторитетный источник? 677 дней].
В программистском фольклоре получила широкое распространение критика объектно-ориентированного подхода в сравнении с функциональным подходом с использованием метафоры «Королевства Существительных» из эссе Стива Йегги[17].
Если попытаться классифицировать критические высказывания в адрес ООП, можно выделить несколько аспектов критики данного подхода к программированию.
Критика рекламы ООП.
Критикуется явно высказываемое или подразумеваемое в работах некоторых пропагандистов ООП, а также в рекламных материалах «объектно-ориентированных» средств разработки представление об объектном программировании как о некоем всемогущем подходе, который магическим образом устраняет сложность программирования. Как замечали многие, в том числе упомянутые выше Брукс и Дейкстра, «серебряной пули не существует» — независимо от того, какой парадигмы программирования придерживается разработчик, создание нетривиальной сложной программной системы всегда сопряжено со значительными затратами интеллектуальных ресурсов и времени. Из наиболее квалифицированных специалистов в области ООП никто, как правило, не отрицает справедливость критики этого типа.
Оспаривание эффективности разработки методами ООП.
Критики оспаривают тезис о том, что разработка объектно-ориентированных программ требует меньше ресурсов или приводит к созданию более качественного ПО. Проводится сравнение затрат на разработку разными методами, на основании которого делается вывод об отсутствии у ООП преимуществ в данном направлении. Учитывая крайнюю сложность объективного сравнения различных разработок, подобные сопоставления, как минимум, спорны. С другой стороны получается что ровно так же спорны и утверждения об эффективности ООП. Производительность объектно-ориентированных программ.
Указывается на то, что целый ряд «врождённых особенностей» ООП-технологии делает построенные на её основе программы технически менее эффективными, по сравнению с аналогичными необъектными программами. Не отрицая действительно имеющихся дополнительных накладных расходов на организацию работы ООП-программ (см. раздел «Производительность» выше), нужно, однако, отметить, что значение снижения производительности часто преувеличивается критиками. В современных условиях, когда технические возможности компьютеров чрезвычайно велики и постоянно растут, для большинства прикладных программ техническая эффективность оказывается менее существенна, чем функциональность, скорость разработки и сопровождаемость. Лишь для некоторого, очень ограниченного класса программ (ПО встроенных систем, драйверы устройств, низкоуровневая часть системного ПО, научное ПО) производительность остаётся критическим фактором. Критика отдельных технологических решений в ООП-языках и библиотеках.
Эта критика многочисленна, но затрагивает она не ООП как таковое, а приемлемость и применимость в конкретных случаях тех или иных реализаций её механизмов. Одним из излюбленных объектов критики является язык C++, входящий в число наиболее распространённых промышленных ООП-языков.
Значит по твоему изобретать велосипед снова не стоит или вобще пытаться что то изобретать, наверно ты думаешь что человечество уже достигло пика своего развития и стремиться уже некуда?
Я же не говорил что нужно именно сайт знакомств, если есть свои идеи лучше я готов заняться. Но даже если делать сайт знакомств, есть разные подходы к решению этой задачи и мне хотелось бы сделать более удобный и эффективный сайт чем все уже существующие.
Все понятно ты судишь о книжке по обложке да название может не особо потому что я допустил опечатку а исправить возможности на этом форуме нету. "Ищу партнера..." было оригинальное название.
Но ты же нашел мою тему и написал в ней так что это не факт что никто больше не ответит.
Есть такое понятие оффтопик, создай тему ООП против Процедурного стиля в любом разделе дай мне ссылку и я отпишусь там.
Здесь давай лучше по теме, обсудим твоюю точку зрения "у тебя все равно ничего не получится" "никто все равно не ответит", в чем именно ты видишь проблему в моем предложении партнерства в чем "не адекватность" давай также по пунктам как ты сделал выше?
Друзья товарищи можно не превращать эту тему в "процедурный стиль против объектного" есть миллиард таких дискусий в интернете этот вопрос спорный четкого ответа и доказательств нету ни у одной тороны, это выбор каждого програмиста.
Можно создать отдельную тему для этого я с удовольствием поделюсь своей точкой зрения на этот вопрос, тут же я не оскорбляю любителей ООП а просто говорю что мне это не интересно я имеюю право на выбор или нет?