Полностью сбой в OOP/MVC

Хорошо, это моя вина. Я никогда не учился программированию в школе, и поэтому я всегда получаю код спагетти. Мне всегда нравятся разные шаблоны и они стараются понять их хотя бы на базовом уровне.Полностью сбой в OOP/MVC

MVC - мой самый страшный страх, и я думаю, что я никогда не смогу использовать его преимущества из-за того, что я не понимаю его основ.

Моей актуальный вопрос/проблема выглядит следующим образом:

Фронт-контроллер вызывает класс «ядро», который делают некоторые инициализации, то он вызывает фактический контроллер с правильными действиями/параметрами. Контроллеры всегда расширяют класс Core, поэтому я могу использовать его переменные и т. Д. Они прекрасно работают вместе, но вот моя настоящая проблема.

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

В этом случае у меня есть два (плохой) выбор:

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

Я вижу много возможных проблем в моем подходе:

Контроллеры всегда расширяя класс «ядро»
контроллер «ядро» удерживает объект базы данных, так и без него я не могу получить доступ к Db
функции базы данных (например, получение продукта) в контроллерах, но я не могу получить доступ к ним, потому что они всегда называя первую (расширяющую проблемой «ядром» снова)

Пожалуйста, скажите мне:

Где самая большая проблема в моем подходе и где я могу это исправить?

Примечание:

Пожалуйста, не рассматривать это как общий вопрос, я думаю, что это отвечает вещь. Если вам нужно какое-то разъяснение, попросите его, и я постараюсь облегчить ситуацию.

Спасибо за ваше драгоценное время, Fabrik

источник

2010-09-02 fabrik

Расширение «основного» класса звучит как epic oo. :) Вместо этого введите базу данных в контроллер. Кроме того, вам нужен только один контроллер, а не передний контроллер и «фактический контроллер». – bzlm

@bzlm: Я вижу точку в вашем комментарии, но я не вижу правильного пути. «Core» был создан для хранения множества часто используемых важных методов/переменных. Где я могу держать их, если не в нем? Фронтальный контроллер выполняет свою работу точно, как угодно (диспетчер и т. Д.), Это важно. – fabrik

Посмотрите этот ответ и его комментарии http://stackoverflow.com/questions/3626955/totally-failed-in-oop-mvc/3627102#3627102 – bzlm

Ваша самая большая проблема имея "Core" класс, избавитесь от него как можно скорее. Кстати, FrontController - это не единственный способ делать вещи MVC.

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

источник

2010-09-02 12:33:54

Как вы оцениваете это самая большая проблема? Существует множество применений для общего «основного» класса. Ознакомьтесь с [Lithium Framework] (http://lithify.me/), они используют его для подавляющего большинства своих классов ... – ircmaxell

Большинство OO-фреймворков основаны на классе «Объект» как основе всех классов. Важно помнить, почему вы используете наследование и убедитесь, что это по правильной причине. Контроллеры, основанные на базовом классе контроллера, имеют смысл, класс доступа к данным (т. Е. Репозиторий), полученный из класса Controller, не имеет смысла. – Lazarus

Люди, основной класс уродливый дизайн. Период. Что общего между контроллерами, данными и полезными объектами? Что это все объекты? Это не имеет никакого смысла. Я согласен с тем, что эти контроллеры могут быть получены из некоторого класса AbstractController, но это наследование не должно использоваться так, как описано в вопросе (т.е. инициализировать и удерживать соединение db) –

Ваши данные представлены в контроллер и вид через модели. Модель может поддерживаться репозиторием, но в зависимости от накладных расходов вы можете предоставить доступ к базе данных в своей модели. Архитектура данных должна быть похожа на это:

(Repository < ===>) Модель < ===> контроллер ---> Просмотр

источник

2010-09-02 12:23:54 Lazarus

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

@fabrik: Нет четкого ответа, потому что не все согласны. Существует множество реализаций, и каждый из них немного отличается. Я предлагаю прочитать [Head First Design Patterns] (http://oreilly.com/catalog/9780596007126) ... Это отличная работа (IMHO) при объяснении этих вещей ... – ircmaxell

@fabrik: В MVC я использую Инверсия управления через инъекцию зависимостей, поэтому, когда мои контроллеры создаются, они заполняются объектом Model. Затем методы контроллера могут извлекать данные из Модели, которые, в свою очередь, были созданы с объектами Репозитория (через DI). Контроллер не вызывает репозиторий, он вызывает модель, модель вызывает репозиторий. Затем Контроллер создает экземпляр «Просмотр» и передает «Просмотр требуемых данных» (как правило, в ViewModel, но это, скорее всего, слишком сложно). Контроллер сидит посередине и инициирует все остальное. – Lazarus

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

Я стараюсь разделить мою логику на view => контроллеры (только для взаимодействия между бизнесом позже и представлением) => бизнес-логика => модели (DTO) => низкий уровень доступа к данным как минимум.

Кроме того, если вам нужны общие вспомогательные функции в ваших представлениях, возможно, создайте несколько расширений, которые помогут.

источник

2010-09-02 12:41:39

Полностью сбой в OOP/MVC

ответ

Смежные вопросы