наши рабочие классы для работы с бд

Статус
В этой теме нельзя размещать новые ответы.
Slayter спасибо, по поводу бизнес логик :)
Я вот образования в программировании не имею, посему так досконально все аспекты не изучал, что сам в мануалах нарыл то и есть. Так вот объясни мне зачем вообще искать то чего нет в чем-то. Нет конечно создание стандартов в программировнии вещь нужная, но все таки.
Выше представлены скрипты простых классов по работе с БД (кода - пару строк) а вы уже приплели какую-то бизнес-логику :)

И дай плиз ссылки где про MVC почитать можно (что такое с чем едят) хочу просветится, а то блин прочитал твои посты нифига не понял - для меня пока то что выше бессмыслица :nezn:

Еще по поводу безопасности. Вот в PDO проблема автоматом решается встроеной функцией prepare для SQL запроса, на уровне библиотеки автоматически заменяются служебные знаки. Но у многих программеров есть такая тенденция (больше проверок, крепче спишь) поэтому некоторые могут перед помещением в базу, гонять данные и через htmlspecialchars и htmlentitydecode и еще собственных проверок и замен накрутить. Ну не банить же их за это :)
 
Я смотрю ты гаразд языком почесать. :D Смотри - я никогда не говорил, что работа с данными не относятся к модели. Я говорил что что работа с базой данных не отностится к бизнес-логике. Ты просто путаешь работу с данными и работу с базой данных. И вот почему...

Смотри, что есть работа с данными (бизнес-логика)? Логично что это какие-то алгоритмы, по которым с данными что-то будет делаться. Применительно к базе данных это будут хранимые процедуры, триггеры в их числе - с их помощью будет проводиться работа с данными.

Теперь прилепим сюда прослойку для записи/выборки данных из базы данных. Каким боком она влияет на бизнес-логику? А? А если мы эту прослойку выкинем и будем на консоль данные выводить, а считывать с электронного микроскопа к примеру (с помощью другой прослойки естессно). И что? Бизнес-логика изменилась?

Насчет GoF. У меня точно такая книга. Правда я ее только пролистал, но твои слова:
прослойка для субд (вырезано для упрощения восприятия предложения целиком) по GoF она относится к модели в паттерне MVC
в этой книге не подтверждаются (а тем более в приведенном абзаце, который вообще о другом).

P.S. С нетерпением жду продложения. Готов направить адепта на путь истинный. ))

Добавлено через 5 минут
поэтому некоторые могут перед помещением в базу, гонять данные и через htmlspecialchars и htmlentitydecode и еще собственных проверок и замен накрутить.
Вот первый, кто понял значение моей фразы "а-ля htmlspecialchars"... Свершилось. :)

dumber, для ознакомления с шаблонами имхо лучше вот это: - в книге обобщена информация из нескольких источников (включая труды GoF). Информации достаточно что бы понять нужно оно тебе или нет.
 
Simpson, прослойка для субд в наших представлениях разные понятия. В моём представлении прослойка для субд это есть некий абстрактный класс с CRUD и д.р. (но уже не в абстрактном) методами, которые используют некий объект для взаимодействия с базой. Т.е. прослойка обеспечивает именно бизнес-логику. а предоставленный пример именно чётко показывает, что модель работает с данными.

dumber, Для просмотра ссылки Войди или Зарегистрируйся почитай и попробуй состряпать что-нибудь простенькое на ZF.

зы. и про количество кода -- чем его меньше -> тем лучше. иначе читаем Фаулера - Рефакторинг (если в проекте есть файлы с содержанием кода от 1 000 строк[зачастую код можно сократить без ущерба функциональности на довольно внушительные объёмы]), там примеры на java, но восприятию не мешает.
 
Есть предложение: прекращаем холивар - подводим итоги по спорным вопросам...

фильтрация ввода - это не предохранение от SQL инъекций.
да, это один из способов предотвращения (предохранение - это из другой оперы ;)).
По GoF она относится к модели в паттерне MVC
что еще раз доказывает, что прослойка не имеет отношение к бизнес-логике. Страница 20 (в английском - 21 видимо:(
Отношение вид-контроллер - это пример паттерна проектирования стратегия. Стратегия - это объект для представления алгоритма.
и последнее
Т.е. прослойка обеспечивает именно бизнес-логику.
тогда нужно написать редакторам википедии что бы перенесли "прослойку" на уровень бизнес-логики Для просмотра ссылки Войди или Зарегистрируйся. P.S. "Обеспечивает" != "Реализует", путаешь понятия Для просмотра ссылки Войди или Зарегистрируйся.

P.P.S. таки итересно, чем у тебя занимается класс Logger?
 
Товарищи книголюбы. Я извиняюсь но вы фигней маетесь ИМХО.

Slayter

PHP:
require_once 'Zend/Mail/Transport/Smtp.php';
$tr = new
Zend_Mail_Transport_Smtp('mail.example.com');
Zend_Mail::setDefaultTransport($tr);
$select = $db->select();
$select->from('users, subscribedfeeds, feeds', '*');
$select->where('users.Username=subscribedfeeds.username');
$select->where('feeds.feedname=subscribedfeeds.feedname');
$select->where('feeds.lastupdated > subscribedfeeds.lastpulled');
$results = $db->fetchAll($select);
foreach($results as $row)
{
    $email = $row['emailaddress'];
    $fName = $row['firstname'];
    $lName = $row['lastname'];
    $feedName = $row['feedname'];

    $mail = new Zend_Mail ();
    $mail->setFrom ('alerts@chomp.backstopmedia.com', 'Chomp! Alerts');
    $mail->addTo ($email, "$fName $lName");
    $mail->setSubject ('Your feeds have been updated');
    $mail->setBodyText ("One of your subscribed feeds, $feedName, ".
                        "has been updated.");
    $mail->send ();
}

плиз, скриптег отправки email :) Вот только зенд мне даром не надо, свои проекты я на чистом PHP делаю со своими классами, чужие фреймворки не использую.

По поводу книг и сути вопроса кажется въехал. Авторы рассказывают как правильно облегчить свой труд используя уже существующие наработки. Ну и с прицелом на будущее эти наработки должны изначально создаваться так чтобы их легко можно было подстроить в другое приложение это они и называют "шаблонами". Вот правильно кто-то из успешных сказал - "Я толстых книжек не читаю". Если конечно программист не знает как ему самому удобнее тогда конечно, обращаемся к литературе и 3им лицам, а если у человека неплохо развито воображение и он знает чего хочет, тогда впринципе сам может описать свои удачные практики. Пожалуй этим и отличается кодер который пашет на контору в которой работает (при этом мечтая о повышении зарплаты) и крутой спец за которым сами фирмы гоняются лиш бы переманить на свою сторону (и он сам выбирает где ему удобнее) ;)
Считаю ваш спор бессмысленным, а что самое главное абсолютно бесполезным для потенциальных читателей поэтому советую его прекратить. Пусть каждый останется при своем мнении.
 
Что меня больше всего веселит у того же Фаулера - это как он трепетно относится к количеству кода. Дескать, чем меньше кода - тем лучше программа. И потом на двадцати страницах идет объяснение, почему это именно так. Как будто это вовсе не очевидная истина.

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

И потом эти люди упорно смотрят в свои горы файлов и ни на секунду не сомневаются, что их подход правильный. Покажи им гостевую из 20 строк + html - раскритикуют в щепки. И без тени сомнения продолжат свою песню про уменьшение сложности программы и количества кода.

Тот же Zend Framework на десятки тысяч строк - отличный пример такого подхода.
 
Что меня больше всего веселит у того же Фаулера - это как он трепетно относится к количеству кода. Дескать, чем меньше кода - тем лучше программа. И потом на двадцати страницах идет объяснение, почему это именно так. Как будто это вовсе не очевидная истина.

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

И потом эти люди упорно смотрят в свои горы файлов и ни на секунду не сомневаются, что их подход правильный. Покажи им гостевую из 20 строк + html - раскритикуют в щепки. И без тени сомнения продолжат свою песню про уменьшение сложности программы и количества кода.

Тот же Zend Framework на десятки тысяч строк - отличный пример такого подхода.

Не в классах ничего плохого нет, только хорошее. А вот варианты формирования структуры приложения дейтсвительно разные. Этим вообщем-то приложения и отличаются друг от друга.
Про рефакторинги ничего не знаю, да и знать не хочу :)
стандартная структура для рабочего сайта
класс БД => классы работы с данными (страницы, меню продукты => класс формирования страницы из шаблона

все это объединяется единым классом самой страницы. В результате в коде не заблюдишься, что-то поменять не приведет к тотальным изменениям. Эффективность работы тоже на высоте. Баги могут быть в самом коде при допущении ошибок. Какие еще "бизнес-логики нужны"?

;) "все гениальное просто" это фраза актуальна везде в жизни и особенно программинге
 
Сколько не встречал людей, которые критикуют разделение кода от логики "всевдо MVC" (ибо нафига в языке-шаблонизаторе еще один шаблонизатор? :)) - никто толком не понимал ООП и не понимает.

Хотяб до того уровня, чтобы облегчить себе жизнь (каким бы хреновым код не был, он служит для облегчения моей жизни. Так ведь, Slyter? :))

А те, кто пишет хрень про "рефакторинг мне не нужен" - убейте себя, честно. Нахрена тогда вам ООП? Пишите для каждого нового проекта новый код :)

То, что здесь говорится - это для случая: "Написал и забыл". Тот же класс БД (каким бы он паршивым не был) - служит для уменьшения количества кода, для цели "написал и забыл".

А тебе, venetu, в закрытый топик в разделе новичков. Там долго спорили "процедурно vs ооп" :)
 
Jeurey, не коверкай мой ник :smmne:

Короче, небольшая история из жизни.
В апреле 2007 года один из моих давних знакомых (трейдер) порекомендовал меня своему товарищу. С тех самых пор я постоянно с этим товарищем и работаю.

Представляете себе, какое количество кода было написано за это время? Если выкинуть графику, стили, js и пользовательский контент, то размер всего проекта 1,86mb. Это при том, что код написан в кодировке windows1251 и не снабжён документацией. Короче тупо чистый код. Дох** кода.

Где-то в феврале 2008 у меня уже начались проблемы с реализацией постоянно прущих, как из рога изобилия, прямо-таки, идей клиента. Порой, чтобы докопаться до нужного места приходилось так всерьёз задумывать (например, расширить возможности какого-либо уже готового модуля).
Код писался без обдумывания, так как придёт в голову. Хорошо хоть, что к тому времени я уже со Смарти познакомился и отделил представление от самого кода. Короче, писал так, как мне было удобно. Этот подход, действительно, жил, жив и будет жив в небольших проектах. Но как-только ресурс начинает разростаться... то тут уже необходимо следовать какой-либо чёткой структуры. MVC отличный паттерн. Сейчас пишу для того же клиента торговую площадку (уже около 3х месяцев пишу). Кода там уже ОЧЕНЬ приличное количество. Как тут выше написали иерархия довольно сложна и запутанна на первый взгляд... но, когда с этим приходится работать постоянно задаёшь себе вопрос, "а чо, бл**ь, я раньше не использовал этот замечательный паттерн?". счас я слёту могу вникнуть в код. если нужно что-то сделать я уже сразу представляю где эти изменения надо внести.

Изначально контроллеры и модели были у меня обыкновенными классами. Потом я уже посмотрел-посмотрел, и открыл для себя, что в каждом контроллере и моделе около 20 одинаковых строк кода. чо делать? ввёл, так сказать, новую системную единицу "прототип контроллера" а потом и "прототип модели", от которых пронаследовал все контроллеры и модели.

+ в моём старом коде довольно часто встречаются глубоко вложенные условия (представьте себе каково дебажить хотя бы троекратно вложенный иф, где на каждый уровень вложенности приходится по 100-150 строк кода:() от этого отошёл. теперь у меня есть чёткое правило -- в коде НЕТ мест с уровнем вложенности условий более двух. пока я не отрефакторю код до таких критериев я не пишу следующий. Да, разработка замедлилась. В разы замедлилась.

Но, поверьте, MVC экономит миллиарды нервных клеток на будущее... а после 20 ведь они очень-очень ху...о восстанавливаются. :)

Короче, мой вам совет, товарищи разработчики: проектировка не должна занимать времени меньше, чем разработка.

От модели разработки "Getting real" я отошёл, чему очень рад. Данный метод чётко работает только на небольших проектах.



:ah:
 
Slayter, Ну ты собственно сам ответил почему и где нужен рефакторинг, а где он ЗЛО.
Когда работаешь на окладе, удлинение разработки с 1ого месяца до 3х только на руку программисту :) А причина идеальная - современная, новая методика качественной работы "Шеф, я в дальнейшем в разы быстрее буду исправлять иобновлять проект, да и после меня людям все делать проще будет, щас чуть попаримся и рай наступит" Шеф соглашается и работа поехала :)
Если буду идити на работу куда нить, обязательно буду использовать всевозможные паттерны и бизнес логики для удлинения процесса создания ;)

Конечно 90% проф кодеров, как раз и работают на кого нибудь, но есть моменты когда проект делаешь сам, так сказать для себя и своей выгоды. Тогда срок имеет большое значение и зная что разработка продлится полгода вместо 2х месяцев никогда не выберешь такой путь даже если он сделает проект чуть безопаснее и чуть удобнее. Когда работаешь на себя важен только результат - рабочий проект, для этого включается своя голова, для этого выбирается оптимальный вариант - скорости, трудозатрат, надежности. Потимальный вариант для каждого свой. Поэтому Jeurey заявления вроде "тот кто не юзает матыгу, дачником называться не имеет права" просто глупы ;)
ООП - Объектно-Ориентированное Программирование , если программер использует объекты в проекте - он использует ООП, а все остальное это уже навароты, понты и выпендреж и то как он их использует не влияет на его понимание этой простой по сути технологии.
 
Статус
В этой теме нельзя размещать новые ответы.
Назад
Сверху