Будучи главным образом программистом-самоучкой, я опаздываю на игру, когда речь заходит о шаблонах дизайна и тому подобных. Я пишу веб-приложение управления трудоустройством с помощью CodeIgniter.
Я сделал немного MVC ASP.NET/C# и Java в школе, и соглашение заключалось в том, что ваша модель в основном состояла из классов, которые представляли действительные объекты, но также абстрагировала все соединение с базой данных и т. Д. … это довольно стандартный материал MVC из того, что я собрал.
Я полагаю, что я прав, говоря, что CI полностью абстрагирует соединение с базой данных вне поля зрения (если вы не смотрите), что является парным для курса, и модели, которые вы можете создать, могут абстрагировать «общие» методы CRUD немного больше создайте некоторые методы, которые более полезны для конкретной модели.
То, с чем я столкнулся, потому что это отличается от того, с чем я привык с MVC, заключается в том, что всякий раз, когда вы говорите … возвращаете строку из базы данных, соглашение состоит в том, чтобы просто поместить ее в ассоциативный массив или стандартный объект со свойствами, представляющими данные из строки.
В ASP у вас будут фактические классы, которые вы могли бы построить для хранения этой информации. Например, у вас будет класс House и данные будут храниться как свойства (например, bedrooms , bathrooms , address ), и эти методы будут представлять полезные вещи, которые вы могли бы сделать с данными (например, printInfo() может print("$address has $bedrooms bedrooms and $bathrooms bathrooms!') ).
У меня создается впечатление – только из кода, который я видел в Интернете, – что это не стандартный способ делать что-то. Предполагается, что вы просто используете массивы или общие объекты и говорите … do $this->house_model->print_info($houseobject) вместо $houseobject->print_info(); ?
Благодарю.
Несмотря на свои утверждения об обратном, Codeigniter вообще не использует MVC (на самом деле, очень мало веб-фреймворков!), На самом деле он использует архитектуру PAC (представление-абстракция-контроль). По существу, в PAC уровень представления данных передается презентатором (который CodeIgniter вызывает контроллер), а в MVC View получает свои собственные данные из модели. Путаница существует из-за этой неправильной маркировки MVC.
Таким образом, CodeIgniter (и большинство других популярных веб-фреймворков) не поощряют подходящую модель, а просто используют очень рудиментарные данные для доступа к своему месту. Это вызывает большой набор проблем из-за «регуляторов жира». Ни один из кодов, относящихся к домену, не может быть повторно использован.
Дальнейшее чтение:
MVC против PAC
M в MVC: почему модели не поняты и недооценены
Model-View-Confusion часть 1: The View получает свои собственные данные из модели
Это широко распространенная точка смущения в сообществе PHP (статья MVC и PAC идентифицирует проблему как происходящую из сообщества PHP, которая была написана в 2006 году, и ничего не изменилось, если что-то ухудшилось, потому что есть больше рамок и руководств обучая ошибочное определение MVC.) и почему люди, смотрящие на PHP-код MVC, которые пришли из фонового внешнего веб-разработки, понятны, запутались. Большинство реализаций MVC в PHP не являются MVC. Вы правы в том, что модели мышления должны быть правильно структурированы, а CodeIgniter неправильно маркировать себя как MVC.
контроллер
// get the houses result from the model // return it as an object if( ! $houses = $this->house_model->findHouses($search) ) { // if no results - call a no results view $this->load->view( 'no_results', $data ); } else { // pass the houses object to data so it automatically goes to view data['houses'] = $houses ; // Call your view $this->load->view( 'house_results', $data ); }
Посмотреть
// we already know we have at least one house, // thats what the controller is for, so we dont need to do an isset() etc for $houses foreach $houses as $house : echo 'This fine house at ' . $house->address . 'has '. $house->bedrooms . ' bedrooms and ' $house->bathrooms . ' bathrooms' ; endforeach ;
очевидно, что есть разные способы создания этого окончательного предложения в представлении, но идея заключается в том, что к тому времени, когда мы дойдем до представления, это будет как можно проще.
поэтому для сложных запросов, таких как Покажите мне все дома рядом с хорошими школами, с 2 спальнями и комнатой для моего любимого Оцелота. То, что происходит в модели. все беспорядочные условия и бизнес-правила. представления должны быть конкретными – если у вас нет результатов – тогда просто не показывайте результаты без результатов. Versus – выполнение проверки результатов в представлении, а затем изменение отображения на основании результатов. тем более конкретным вы сделаете представление, тем легче будет его строить, и это будет способствовать выбору вариантов в контроллере и модели.
CodeIgniter очень гибкий, когда речь заходит о шаблоне MVC, и это действительно зависит от того, насколько вы хотите обеспечить его соблюдение. Большая часть кода CodeIgniter, который вы найдете в Интернете, точно так же, как вы описываете, модели – всего лишь набор методов на самом деле и не стремятся строго представлять объект.
Вы можете, однако, кодировать этот путь, если вы так любите в CI (и это то, что я часто делаю). Это делает код намного более удобным и удобным для чтения, и кажется, что все выглядит лучше.
PS – Если вы просто попадаете в MVC на PHP, вам может понадобиться немного оглянуться. Такие структуры, как CodeIgniter и CakePHP, являются (несколько) предыдущего поколения. CI первоначально был написан для PHP4, где поддержка ООП была любопытной в PHP. Вилка CI, называемая Fuel , была специально создана для решения этой проблемы (хотя я считаю, что в какой-то момент они просто решили, что им лучше будет переписывать ее с нуля). У CI есть преимущество в том, что у вас много документации и онлайн-помощь, поскольку она более широко используется, чем Fuel.