Ну как бы изначально объект лента принадлежит объекту пользователь, или проще у пользователя есть лента)
И что бы разослать другим пользователям (друзьям или еще кому), как бы сначала нужно из бд воссоздать объекты этих пользователей, а потом к каждому из них применить типа $user->addLenta($post)
Понятное дело что так это очень и очень затратно, но разве это не логично с точки зрения ооп?
Всем привет.
Начинаю осваивать ооп, и появилась одна проблема, точнее не понимание как ее правильно решить...
И так есть 3 сущности:
1. Пользователь в системе
2. Пост пользователя
3. Лента
У сущности пользователя есть свойства (логин пароль и т.п), одно из действий написать пост.
Для этого действия я решил вынести пост в отдельную сущность (по сути это так и есть), пост можно добавить в избранное и т.п
Также есть лента, пока тока лента постов, в эту ленту передается объект поста.
В действии написать пост, сначала создается объект поста, потом он помещается в ленту..
И все нормально вроде бы, но появилась необходимость сделать как бы рассылку 1 записи в несколько лент других пользователей, исходя из ооп, можно создать несколько десятков объектов лент, и отдать им туда объект записи...
Но если так сделать то получится большое число запросов к бд, да и расход на сами объекты тоже не маленький, так что же получается что ооп там где удобно там юзаем, а там где нет то просто тупо пишем в процедурном стиле?
Или есть какой нибудь супер паттерн, который может решить эту проблему?
Или может я неправильно определил сущности?
Надеюсь проблема понятна.
Ладно, caballero, digi спасибо вам за обсуждение данной темы.
Буду все таки клепать классы (делать дубликаты правил), а по ним рисовать формы...
Так как я считаю что валидация все таки нужна и на сервере.
валидация в основном предназначена для защиты от ошибок ввода а не от преднамеренного ввода неправильных данных. ну введет юзер кривой емайл и что? какой смысл?
смысл в том, что туда можно хоть что впихнуть, даже xss, конечно можно отчищать перед выводом, но
все же, зачем это делать когда модель должна быть корректна...
Загружается страница, генерируется капача с кодом, код записывается в сессию.
Я вижу код, и отправляю не валидные данные, вместе с правильным кодом, обработчику регистрации, и все.
Что помешает произвести такую операцию?
А как насчет записи не валидных данных в модель, если в ручную капчу постом передать, не проверяя повторно данных на клиенте? (Добавление)
Блин, не на клиенте а на сервере
далеко не спокойно, да и капчу можно сделать разной сложности. уверен если у вас будет настолько ценный ресурс что кто то будет сидеть и ломать капчу уж как нибудь вопрос с валидацией решите.
Капчу то можно разно сделать, но вот всем известная рекапча вроде обходиться,
а хотя я ее сам то не всегда ввожу
А вот кстати вспомнил как работает проверка капчи, можно записать не валидные данные и вручную,
если отправить пост запрос, еще и с капчой...
Так что как ни крути, все ровно придется делать проверку и на сервере... (Добавление)
digi пишет:
т.е. может быть выгоднее получится сократить время работы человека, но вложить чуть больше в сервер?
Ну не знаю на yii к примеру тоже можно быстро написать, а работает он быстрее сф.
Так что это дело личных предпочтений что использовать...
сф2 - это не "микро", по этому надо смотреть в сторону например Silex, Laravel4 или если совсем что-то мизерное нужно, то Slim2.
Я не писал что сф это микрофреймворк...
digi пишет:
ЗЫ: в сторону симфони, как полноценного фреймворка, могу добавить только один недостаток - его нужно изучить... без этого никак в остальном претензий нет хоть для маленьких проектов, хоть для больших...
А насчет минусов, думаю можно добавить не высокую производительность, помню тесты были, давно правда, не знаю как там щас, но судя по тому что там все как-то мудренно то вряд ли дело сильно изменилось...
caballero пишет:
так там и валидация не нужна потому что проверка будет выполнятся на уровне сервера БД независимо от того что там пользователь введет или не введет.
Это авторизация, да можно согласиться что там валидацию можно и не делать,
ну а как насчет например изменения данных пользователя, и думаю со временем будут еще случаи...
Кстати насчет капчи, на странице регистрации, думаю не секрет не для кого что такие вещи сейчас можно спокойно обоойти (автоматическая распознавание), и в случае этого в модель попадут не валидные данные...
caballero, у вас вроде бы за плечами большой опыт программирования, как вы сами писали в топиках, как вы сами такие вещи делаете, неужели просто через html и css
велики - это прекрасно! ) я сам их люблю ;)) но вот использовать удобные библиотеки это хорошо ;) и когда пишется какбы "свой" велик, то лучше собирать солянку из лучших решений под себя ;) а для этого разумеется нужно знать что нынче в мире существует ;)
Как я выше уже писал, я смотрел разные фреймворки (признаюсь, symfony так пролестал - не понравился), но суть у всех одна, да и реализации тоже весьма похожи...
Ну там вообще то и так стоит, но вот на странице авторизации ее ставить не нужно,
а правила валидации для логина и пароля нужны, еще один пример изменение данных...
caballero пишет:
потому что эта сущность не будет делать ничего такого чего не сделает простая функция.
Да согласен, но так будет удобнее мне работать с этими так называемыми классами, автозагрузка и тд..
Главная
Помощь
Поиск
Пользователи
Найдено сообщений: 808
