Warning: Cannot use a scalar value as an array in /home/admin/public_html/forum/include/fm.class.php on line 757

Warning: Invalid argument supplied for foreach() in /home/admin/public_html/forum/include/fm.class.php on line 770
Форумы портала PHP.SU :: Версия для печати :: Так устроены Модели у меня, а как у вас?
Форумы портала PHP.SU » PHP » Программирование на PHP » Так устроены Модели у меня, а как у вас?

Страниц (2): [1] 2 »
 

1. chalenkoa - 18 Сентября, 2013 - 12:13:50 - перейти к сообщению
Я использую MVC. С контролерами и шаблона, мне все понятно, но вот модели, тут не все так просто. Некоторое время назад мне нужно было определиться какая структура у меня будет у моделей, и я пошел искать чужой опыт. Нашел только это http://laravel[dot]ru/docs/v3/models это и было принято за основу. Я не буду говорить про то как устроено там, а буду о том к чему я сам пришел и сейчас использую.

Модели у меня делаться на 3 типа

1. Сущности (лежат в \Models\Entities и имеет такое же пространство имен)
2. Хранилища (в \Models\Repositories)
3. Сервисы (в \Models\Services)

Сущности
========
Это простейшие объекты, являющиеся по сути прямой проекцией данных из БД.

PHP:
скопировать код в буфер обмена
  1.     class User {
  2.         public $id;
  3.         public $login;
  4.         public $pass_hash;
  5.     }


У сущностей могут быть методы напрямую относящиеся к ним (читай к данным)
Поэтому методы не могут быть статическими, то есть методы работают с конкретным объектом, созданным на основание данных из БД.

PHP:
скопировать код в буфер обмена
  1.     class User {
  2.         ...
  3.         public function delete() {}
  4.         public function setPassHash() {}
  5.     }


Например, не может быть такого метода, потому что это просто не логично, добавить конкретному пользователю другого пользователя нельзя. Добавить пользователя можно будет с помощью хранилища работающего с пользователями, о чем ниже.

PHP:
скопировать код в буфер обмена
  1.     class User {  
  2.         public static function add($user) {}
  3.     }



Хранилища
=========
Хранилища — это объекты, исключительно со статическими методами, помогающими получать сущности из БД, добавить новые и т.п.

PHP:
скопировать код в буфер обмена
  1.     class Users {
  2.         /** @return \Models\Entities\User */
  3.         public static function getByLogin($login) {}
  4.    
  5.         /** @return \Models\Entities\User */
  6.         public static function create($login, $pass) {}
  7.    
  8.         /** @param \Models\Entities\User $user */
  9.         public static function add($user) {}
  10.     }


Чего не должно быть в хранилище? Логики работы с данными. Например, если нам нужно как-то данные из БД обработать для получения результата, то это уже задача для сервиса, о которых ниже.
Такой код в хранилище недопустим.

PHP:
скопировать код в буфер обмена
  1.     class Users {
  2.         /** @return bool */
  3.         public static function isAdmin($user) {
  4.                 return self::inGroup($user, 'Admin');
  5.         }
  6.    
  7.         /** @return bool */
  8.         private static function inGroup($user, $group) {}
  9.     }


Сервисы
=======
Так как это последний тип моделей, все что не подошло для предыдущих двух помещаем сюда Улыбка Звучит не серьезно, но в моем реальном проекте, что бы здесь не размещалось, не противоречит названию Сервис, так что помойкой это врятли станет.

Продолжим наши примеры с пользователем и приведём, что бы могло быть сервисом, кроме не подходящего для хранилища, но подходящего для сервиса, примера выше.

PHP:
скопировать код в буфер обмена
  1.     use \Models\Repositories\Users;
  2.    
  3.     class Auth {
  4.         public static function reg($login, $pass){
  5.                 $user = Users::create($login, $pass);
  6.                 Users::add($user);
  7.         }
  8.    
  9.         public static function login($login, $pass){
  10.                 $user = Users::getByLogin($login);
  11.                 $result = self::_checkPass($pass, $user->pass_hash);
  12.                 return $result;
  13.         }
  14.    
  15.         private static function _checkPass($pass, $pass_hash) {}
  16.     }


В чем вопрос
============
А вопросов собственно несколько

1. Какие очевидные недостатки вы видите в используемой мною схеме?
2. Какие предложения по улучшению?
3. Если ли у вас какое-то разбиение на типы моделей, что используете вы?

Предвидя будущие вопрос сразу говорю, что про ORM знаю, не использую, не уговаривайте использовать не буду так как работаю над большим проектом где ORM нет и переписывать систему на ORM не буду. В новых проектах пока которых не предвидеться возможно буду использовать ORM, но подозреваю что использование ORM не отменяет необходимости разбиения моделей на разные типы.
2. caballero - 18 Сентября, 2013 - 12:24:34 - перейти к сообщению
индуский код

все это можно свести к сущностям а хранилища и сервисы - статические методы сущностей.
3. chalenkoa - 18 Сентября, 2013 - 12:30:03 - перейти к сообщению
caballero пишет:
индуский код

Отличное начало.
С вами разговор закончен
4. caballero - 18 Сентября, 2013 - 12:51:00 - перейти к сообщению
очередное самолюбивое и самоувереное школоло.

я тебе по делу написал. Сущности на основе паттерна Active record и статических фабричных методов перекрывают 90% функционала. Остальное можно сделать хелперными классами -
всегда будет витиеватый кусок логики который не впишется в структуру моделей и придется выполнять нативный SQL.

если считаешь что архитектура которую ты слямзил - клевая а не индусская - зачем вопросы задаешь.
5. imya - 18 Сентября, 2013 - 15:09:42 - перейти к сообщению
chalenkoa пишет:
С вами разговор закончен

Вы зря так, послушайте, что вам умный человек говорит Подмигивание
6. DelphinPRO - 18 Сентября, 2013 - 16:10:10 - перейти к сообщению
мама родная!!! к чему такие сложности? Все гениальное - просто.
7. chalenkoa - 18 Сентября, 2013 - 16:17:37 - перейти к сообщению
DelphinPRO

Люблю когда все красиво Улыбка
8. avtor.fox - 18 Сентября, 2013 - 16:18:27 - перейти к сообщению

chalenkoa пишет:
Люблю когда все красиво

Странное у Вас понятие о красоте.
9. chalenkoa - 18 Сентября, 2013 - 16:27:21 - перейти к сообщению
avtor.fox пишет:

chalenkoa пишет:
Люблю когда все красиво

Странное у Вас понятие о красоте.


Ну это как раз нормально, на вкус и цвет товарища нет Улыбка
Интересно было вдруг кто то что то еще придумал кроме как все хранить в одной сущности.
10. Zuldek - 18 Сентября, 2013 - 16:39:35 - перейти к сообщению
Сторонником тонкой модели и толстого контроллера был и остаюсь Хм
именно вот поэтому:
Цитата:
всегда будет витиеватый кусок логики который не впишется в структуру моделей и придется выполнять нативный SQL.
11. caballero - 18 Сентября, 2013 - 17:17:12 - перейти к сообщению
вообще то бизнес-логика должна относится к модели. Просто модель обычно более широкое понятие чем набор классов. Поэтому в модель могут входить как Entity для выполнения элементарных операций так и более сложный функционал.
Модель вообще может быть отдеена от приложения -это может быть отдельный модуль к которому ходят через апи или вебсервисы. Или, как раньше делали, - бизнес-логика реализуется хранимыми процедурами
12. DeepVarvar - 18 Сентября, 2013 - 17:20:36 - перейти к сообщению
Да человек всеравно не понимает и стоит на своем.
Пусть так и остается, раз слушать не хочет.
Когда настанет ключевой момент в будущем - он вспомнит этот топик и сядет переписывать.
13. chalenkoa - 18 Сентября, 2013 - 18:40:09 - перейти к сообщению
DeepVarvar пишет:
Да человек всеравно не понимает и стоит на своем.
Пусть так и остается, раз слушать не хочет.
Когда настанет ключевой момент в будущем - он вспомнит этот топик и сядет переписывать.

Не понял о чем вы.
14. esterio - 18 Сентября, 2013 - 19:21:13 - перейти к сообщению
chalenkoa
Если Вы пришли на форум с вопросами значит готовы выслушать критику, которая по любому будет, так как каждому свое.

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

Теперь по существу
Возмем мой любимый Yii - так там модель имеет:
- данные с базы
- допольнительные аттрибуты
- валидация
- связи
- текстовое описание полей для аттрибута label
- ошибкы заполнения
- behavior-ы
- action-ы
- поиск по primary key
- поиск по аттрибутам
- поиск по sql
- поиск одного, несколькых и всех записей
- структуру таблицы
- кеширование
- типи полей
- работа с формой
ну и много еще чего

вот видите сколько обьязоностей берет на себя модель?
У Вас же все ети три типа моделей можна смело обеденить в одну можель. Ну и не всегда модель должна работать с базой.
15. chalenkoa - 18 Сентября, 2013 - 20:39:15 - перейти к сообщению
esterio
Круто что то по теме.
Я не работаю с Yii поэтому было бы интересно если бы ты рассказал подробнее о том что там с моделями в том аспекте что я предложил к обсуждению.
В том виде что ты дал информацию, она мало полезна извини.

 

Powered by ExBB FM 1.0 RC1