встречный вопрос - контроллер что принимает и передает во вьюшку?

речь о MVC именно?

не подменяй понятия - модель это и данные в том числе

речь о MVC именно?

есть сомнения?

не могу уловить суть вашего спора, вот и уточняю)

не могу уловить суть вашего спора, вот и уточняю)

мне вот интересно что такое модель, и что она из себя представляет и почему она и в контроллере тусуется и во вьюшке

)))

именно модель

именно модель

да вообще че она в MVC то забыла проблема в том что ты считаешь моделью одну строчку из таблицы тобишь один экземпляр класса

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

мда

ты мне утверждал что массив является моделью

ты мне утверждал что массив является моделью

так давай развивать класс содержит один массив - модель? зачем делать класс если можно обезличенный массив гонять? от того что я массив не обернул я не могу его моделью назвать? где логика

тут ты прав, логики нет заворачивать массив в класс. с этим никто и не спорит

и он от этого моделью не станет

смысл в том что модель это в первую очередь данные - а вот как ты их носишь это твое дело - хочешь в классе хочешь в массиве, пакете или чемодане - дело твое - но то что ты принес в контроллер - это и есть модель

Ну например, есть таблица в базе данных Article. Есть у нас и модель соответсвующая Article со всеми аттрибутами и прочим. Есть и ArticleController. В самой модели, методов будет немного, они будут обращаться к б.д. и вытягивать то, что просит метод. А вот все манипуляции над моделями будут производиться именно в контроллере. А во вьюшке же могут быть только экземпляры модели. (уже обработанные в котроллере). Т.е. не "тусуются" модели и там и там:) Во вьюшке - экземпляры, а контроллер создает эти самые экземпляры

"модель это в первую очередь данные" интересно...я думал модель что-то достает из бд, и что-то передает из контроллера...а она оказывается себя по рукам пускает

"модель это в первую очередь данные" интересно...я думал модель что-то достает из бд, и что-то передает из контроллера...а она оказывается себя по рукам пускает

достает из базы вроде как репозиторий или дао

репозиторий...весь чтоли?

своими сравнениями вы меня пугаете

так вижу недопонимание - модель в базу не ходит - она наполняется данными с помощью например ORM

что такое orm ?

технология программирования, которая связывает базы данных с концепциями объектно-ориентированных языков программирования, создавая «виртуальную объектную базу данных».

напрямую не ходит, естесственно. Класс-модель описывает параметры, которые должен/может содержать экземпляр этой самой модели

Object-Relational Mapping - не слышал? или ты думал что это и есть модель))

напрямую не ходит, естесственно. Класс-модель описывает параметры, которые должен/может содержать экземпляр этой самой модели

лучше расскажи откуда в контроллере данные если в него они не пришли? что значит создает? я про это и говорю что в контроллер пришла модель которую он тоесть контроллер перевернул с ног на голову и отдал вьюшке - модель пришедшая не равна модели ушедшей - что говорит о создании еще одной модели

Какая еще модель "пришедшая"?)

куда пришедшая?) в контроллер?)

куда пришедшая?) в контроллер?)

да

видимо я что-то упустил...или не догоняю...про orm я конечно слышал, и не считаю ее моделью... даже не знаю правильно ли я пишу код...вот пример реализации... модель постов: namespace app\models; use Core\Model; class Posts extends Model { protected $table = 'posts'; }

абстрактная модель точнее подключение orm : namespace Core; abstract class Model { protected $table = ''; public function __construct() { $conf = parse_ini_file('app/config/config.conf'); \ORM::configure(array( 'connection_string' => '' . $conf['driver'] . ':host=' . $conf['host'] . ';dbname=' . $conf['name'] . '', 'username' => $conf['username'], 'password' => $conf['password'] )); \ORM::configure('driver_options', array(\PDO::MYSQL_ATTR_INIT_COMMAND => 'SET NAMES utf8')); } public function get($id) { return \ORM::for_table($this->table)->find_one($id); } public function getAll() { return \ORM::for_table($this->table)->find_many(); } }

не существовало модели пока контроллер её не создал, нет никакой "пришедшей". Было только описание будущей модели)

контроллер namespace App\Controllers; use app\models\Posts; use Core\View; class MainController { public function indexAction() { $posts = new Posts(); $view = View::init(); echo $view->render('pages/posts/all.twig', [ 'title' => 'Блог', 'posts' => $posts->getAll() ]); } }

контроллер создал экземпляр модели, чтобы понятнее было

вид: {% block content %} {% for post in posts %} <h2 class="blog-post-title"><a href="/post/{{ post.id }}">{{ post.title }}</a></h2> <p class="blog-post-meta">{{ post.date | date }}</p> {{ post.content[:150] }} {% endfor %} {% endblock %}

ну и чего не так в твоем коде то?:)

хз, может я не прав...мне Олег крышу свернул

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

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

где тут сказано что модель это не массив? модели данных приложения довольно расплывчатое понятие - это может быть как все данные из базы или одна буква - и в обоих случаях это модель

и именно модель приходит в контороллер

точнее контроллер ее вызывает и она приходит))

class Model { public function get_data() { bla bla bla } }

да это модель и в нее кидаешь массив)

да это модель и в нее кидаешь массив)

вот серьезно - с чего ты взял что массив не может быть моделью в рамках MVC?

вот серьезно - с чего ты взял что массив не может быть моделью в рамках MVC?

с того что ты модель в контроллер запихнул

точнее в массив данных

и обозвал этот массив данных моделью

с того что ты модель в контроллер запихнул

а куда она по твойму идет из базы? сразу во вьюшку?

модель данных приложения - Это что? мои данные лежат в массиве например

class Model_Portfolio extends Model { public function get_data() { return array( array( 'Year' => '2012', 'Site' => 'http://DunkelBeer.ru', 'Description' => 'Промо-сайт темного пива Dunkel от немецкого производителя Löwenbraü выпускаемого в России пивоваренной компанией "CАН ИнБев".' ), array( 'Year' => '2012', 'Site' => 'http://ZopoMobile.ru', 'Description' => 'Русскоязычный каталог китайских телефонов компании Zopo на базе Android OS и аксессуаров к ним.' ), // todo ); } }

или мои данные это и есть массив

это что?

или мои данные это и есть массив

да

это что?

вот ты странный - у тебя же не возникает спора что массив это не array - хотя называются по разному показал мне самописный класс у которого имя Модель - что это доказывает? что модель должна только так выглядеть?

class Model_Portfolio extends Model { public function get_data() { return array( array( 'Year' => '2012', 'Site' => 'http://DunkelBeer.ru', 'Description' => 'Промо-сайт темного пива Dunkel от немецкого производителя Löwenbraü выпускаемого в России пивоваренной компанией "CАН ИнБев".' ), array( 'Year' => '2012', 'Site' => 'http://ZopoMobile.ru', 'Description' => 'Русскоязычный каталог китайских телефонов компании Zopo на базе Android OS и аксессуаров к ним.' ), // todo ); } }

Этот метод не возвращает модель) Он возвращает массив с данными

идем дальше

class Controller_Portfolio extends Controller { function __construct() { $this->model = new Model_Portfolio(); $this->view = new View(); } function action_index() { $data = $this->model->get_data(); $this->view->generate('portfolio_view.php', 'template_view.php', $data); } }

а вот

а вот new - и создает экземпляр модели. т.е. $model1 = new Article($id1); $model1->body = "lol"; $model2 = new Articke($id2); $model2->body = "ololo";

идем дальше

я же не против того что из базы данные идут в контроллер а из него во вьюшку вижу и ты не против ты против того чтоб эти данные назвать моделью я интересуюсь почему?

потому что эти данные не являются экземпляром какой-либо модели

точнее в зависимости от того как эти данные выглядят - то они модель а то и нет - в общем мутно

модель забирает данные из бд, как она может быть данными?

нет какой мути:) Все предельно прозрачно:)

модель забирает данные из бд, как она может быть данными?

мы же вроде разобрались что из базы их не модель забирает

ERROR: S client not available

а мы их маппим в модель

модель забирает данные из бд, как она может быть данными?

модель сама по себе ничего не забирает и ничего с ебе не содержит кроме логики будущего экземпляра. А вот созданный экземпляр можно уже заполнять

мужики, надоели уже, чес слово. На одном месте толчетесь

Кирилл, спасибо, всё разьяснил, пойду я работать

И я пойду) Времени чот много тут оставил) Пиши, коль чего

модель сама по себе ничего не забирает и ничего с ебе не содержит кроме логики будущего экземпляра. А вот созданный экземпляр можно уже заполнять

я говорю не о какойто конкретной реализации а о самом паттерне не привязанному к языку, и если внимательно почитать например тут 2.Активная модель — модель оповещает представление о том, что в ней произошли изменения, а представления, которые заинтересованы в оповещении, подписываются на эти сообщения. Это позволяет сохранить независимость модели как от контроллера, так и от представления. то можно увидеть Это позволяет сохранить независимость модели как от контроллера, так и от представления. о какой независимости может идти речь если ты модель в контроллере создал?

ну и выдержка из википедии как раз про трактовку модели как средство доступа к базе Начинающие программисты (особенно в веб-программировании, где аббревиатура MVC стала популярна) очень часто трактуют архитектурную модель MVC как пассивную модель MVC. В этом случае модель выступает исключительно совокупностью функций для доступа к данным, а контроллер содержит бизнес-логику. В результате код моделей по факту является средством получения данных из СУБД, а контроллер представляет собой типичный модуль, наполненный бизнес-логикой, или скрипт в терминологии веб-программирования. В результате такого понимания MVC разработчики стали писать код, который Pádraic Brady, известный в кругах сообщества Zend Framework, охарактеризовал как ТТУК — «Толстые тупые уродливые контроллеры» (Fat Stupid Ugly Controllers)

я говорю не о какойто конкретной реализации а о самом паттерне не привязанному к языку, и если внимательно почитать например тут 2.Активная модель — модель оповещает представление о том, что в ней произошли изменения, а представления, которые заинтересованы в оповещении, подписываются на эти сообщения. Это позволяет сохранить независимость модели как от контроллера, так и от представления. то можно увидеть Это позволяет сохранить независимость модели как от контроллера, так и от представления. о какой независимости может идти речь если ты модель в контроллере создал?

а где вы экземпляр модели тогда создаете, если не в контроллере, я стесняюсь спросить?

а где вы экземпляр модели тогда создаете, если не в контроллере, я стесняюсь спросить?

не нужно смотреть на паттерн с точки зрения какойто конкретной реализации - есть мнение что модель это очень большая штука включающая в себя и базу данных и бизнес логику - и создавать экземпляр этого монстра каждый раз не дешевое удовольствие

Ребята, вклинюсь в дисскусиию. Так а где размещать бизнес-логику? Если контроллер - это чисто валидатор данных с вьюхи?

Получается тогда надо вводить 4-ю сущность

Получается тогда надо вводить 4-ю сущность

на мой взгляд более жизнеспособная схема такова model <> logic <> controller <> viewmodel <> view

первая модель - это объектный маппинг на БД?

первая модель - это объектный маппинг на БД?

да в принципе - но не только - это вообще все данные которые используются - статические глобальные ...

а вообще она и счас такая же но из-за чего все спорят про толсые модели или контроллеры - что немогут понять что лучше model <> (logic <> controller <> viewmodel) <> view или (model <> logic) <> (controller <> viewmodel) <> view

Кирилл уже печатает минут 15

не нужно смотреть на паттерн с точки зрения какойто конкретной реализации - есть мнение что модель это очень большая штука включающая в себя и базу данных и бизнес логику - и создавать экземпляр этого монстра каждый раз не дешевое удовольствие

Всё зависит от конкретного проекта - монстр там будет или нет. А для чего тогда создавать модель, пусть даже и "монстра", если не вызывать её?) Понятно что модель ни в коем случаем не должна ограничиваться просто описанием набора параметров, которые будут присутствовать в ней. Контроллер, по хорошему - это, "распределитель", который направит куда нужно, исходя из GET запроса, например, вызовет нужный метод модели. Логика модели - только в модели. Контроллеру - "контроллировать" модель (вот такая тафталогия). Женщинам - цветы, детям - мороженое и не перепутай. Всё правильно вы, Олег, говорите за исключением одной очень серьезной вещи - массив - это никак не модель ;) Есть класс описывающий модель, содержащий в себе все её методы. Есть экземпляр модели, который вы создали через контроллер и, например, целиком направили во вьюшку. Как было он экземпляром модели, так и остался, т.е. вызов во вьюшке $model->getName(); сработает. А вот если вы контроллером передали во вьюшку не модель, а массив данных $data = ["name" => "Lolo", "fake" => true], то кроме этих данных у вас ничего больше и нет.

да работаю параллельно:)

запятых то запятых наставил) Благо что в программировании это не требуется)

Всё зависит от конкретного проекта - монстр там будет или нет. А для чего тогда создавать модель, пусть даже и "монстра", если не вызывать её?) Понятно что модель ни в коем случаем не должна ограничиваться просто описанием набора параметров, которые будут присутствовать в ней. Контроллер, по хорошему - это, "распределитель", который направит куда нужно, исходя из GET запроса, например, вызовет нужный метод модели. Логика модели - только в модели. Контроллеру - "контроллировать" модель (вот такая тафталогия). Женщинам - цветы, детям - мороженое и не перепутай. Всё правильно вы, Олег, говорите за исключением одной очень серьезной вещи - массив - это никак не модель ;) Есть класс описывающий модель, содержащий в себе все её методы. Есть экземпляр модели, который вы создали через контроллер и, например, целиком направили во вьюшку. Как было он экземпляром модели, так и остался, т.е. вызов во вьюшке $model->getName(); сработает. А вот если вы контроллером передали во вьюшку не модель, а массив данных $data = ["name" => "Lolo", "fake" => true], то кроме этих данных у вас ничего больше и нет.

все зависит от конкретного проекта? но в любом случае массив не может быть моделью? странно звучит

Добрый день)

это я про монстра же) Размер модели будет зависеть от проекта. Глупо даже аксиому такую пояснять:)

Доброго дня)

это я про монстра же) Размер модели будет зависеть от проекта. Глупо даже аксиому такую пояснять:)

класс может быть моделью?

надеюсь это шутка

где вы описываете модель?

надеюсь это шутка

увы но нет

ну так чего? Где модель то описываете? Не так: class Article extends model { /*code*/ } ?)

ну так чего? Где модель то описываете? Не так: class Article extends model { /*code*/ } ?)

нет - это вообще не важно как ее описать так что класс может быть моделью или нет?

Олег, у вас свой я.п. ?

нет - это вообще не важно как ее описать так что класс может быть моделью или нет?

Что за привычка вопросом на вопрос отвечать?) я же спросил - как его описываете вы!"?)

Олег, у вас свой я.п. ?

да причем тут язык вообще? паттерн что описан на конкретном языке и в нем сказано что массив моделью не может быть? я вот немогу понять почему class qqq{$id=1;} может быть моделью а [id=>1] уже все не может - откуда это все берется - где это описано?