Как Вы преобразовываете основанное на странице приложение PHP в MVC?
Вы не можете напрямую передавать параметр в конструктор контроллера FXMLLoader, вместо этого вы получаете контроллер из экземпляра FXMLLoader и вызываете метод на контроллере для инициализации его параметром.
FXMLLoader loader = new FXMLLoader(getClass().getResource("sample.fxml"));
Parent root = loader.load();
ViewController viewController = loader.<ViewController>getController();
viewController.initParameter(parameter);
11 ответов
так как Ваш босс счастлив модным словечком, скажите ему искать, "осуществляют рефакторинг"
Какой смысл того, чтобы иметь одно представление на контроллер? Что потребность там для разделения проблем, когда все - просто подобранная пара?
Я был бы более склонен записать контроллер, который управляет несколькими представлениями, которые связаны в некотором роде. Например, вышеупомянутые добавляют/просматривают/редактируют пользователя. Вы хотели бы держать схожую функциональность вместе вместо того, чтобы перерыть много файлов для кода, который Вы хотите. Также удобно иметь все определенные методы (для конкретного объекта) в одном месте. Делает обслуживание НАМНОГО легче.
Я работал над проектом с помощью платформы PHP, которая создала отдельный файл на 'действие'. Названный как 'объект (действие)' и это стало КОШМАРОМ для поддержания.
Я использовал Django на некоторое время теперь, который сохраняет все модели в одном файле, все представления (контроллеры) в одном файле и шаблоны (представления) отдельно. [Django не является MVC, но в этих целях, давайте притворимся, что это]. Это позволяет Вам группироваться, общий код в одном месте и обслуживании становится намного легче.
Мой единственный совет - не пытаются организовать Ваш проект на основе некоторого идеала MVC. Организуйте свой проект, как он имеет смысл Вам и Вашему домену. MVC был предложен, чтобы ограничить сложность, не увеличить ее.
Для Вашего примера плана я превратил бы это в контроллер. www.example.com/plan/1../plan/2 и т.д. Это имеет смысл, потому что действия логически группируются для формирования некоторой задачи.
Контроллер, по-моему, должен использоваться для управления задачей или объектом. Это - методы, должны быть определенные действия, требуемые выполнять ту задачу или изменять/использовать объект.
Немного вне темы к Вашему вопросу... из любви к богу не забывают Ваши старые URL. Так как причина, то, что минута, Вы зеркально отражаете переключатель на новом сайте и его симпатичных URL, всем агрегированном содержании сохраненным поисковыми системами, будет медленно истекать, удаляя Вашу статистику SEO путь.
ОБНОВЛЕНИЕ: Если я пытаюсь придерживаться одного контроллера на представление... Я буду затем сохранять код на запрос к минимуму, но действительно ли это - лучший способ?
Если бы я понимаю Вас правильно, каждый контроллер произвел бы одну страницу. Это может быть действительно плохой идеей, что я испытал на собственном опыте в положении обслуживания. Если у Вас есть содержание, которое действительно не соответствует хорошо к парадигмам OO, затем помещает его в категорию: пресс-релизы, один offs, информационный, и т.д. и палка те в контроллер, который служит просто тем представлениям или еще лучше многим контроллерам на категорию, чтобы выйти из-под более мелкомодульного контроля.
Платформа "MVC" я имел дело с этим, сделала один контроллер для просмотра, быстро стал замысловатой путаницей с большим количеством взломов и запутанного кода.
У меня есть приблизительно 12 страниц формы, которые используются для создания "плана".
Я должен был сделать что-то подобное и настолько глупо, как это кажется, имение контроллера "planningform" является, вероятно, лучшим. Да существует несколько таблиц для питания, но можно сделать простой материал как $ _SESSION ['plannerController'] ['subject|action'] [ключ] [значение] для хранения каждой части формы в целом под контролем. Наличие каждой части дескриптора метода многостраничной формы может также быть преимуществом (напр. В чем, если Ваш босс заявляет, они только нуждаются 6 из 12 страниц или что, если часть 7 становится действительно сложной и должна наполнить как автозавершение ajax).
группировка механизма не обязательно использование его, потому что у них есть что-то связанное друг с другом.
Мне обычно нравится один класс, одна парадигма цели, но иногда просто не имеет смысла пытаться сделать это. Существуют случаи, куда его ясное, прямо из учебника OO и другие времена академический БАКАЛАВР НАУК может пойти к черту. Ваша попытка найти материал, который не соответствует форме OO, таким образом, можно предпринять шаги назад и попытаться объединить вещи в общие категории.
Я прошел что-то вроде этого в прошлом году. Я преобразовал свои главным образом статические страницы веб-сайта PHP для использования Платформы Kohana PHP. Я заставил каждый веб-сайт разделить контроллер с представлениями для отдельных страниц. Основные просмотры страницы включали другие представления для заголовка и нижний колонтитул. Некоторые представления, такой что касается статей, были допускающими повторное использование различными контроллерами. Результатом был сайт MVC с той же страницей URL как исходный веб-сайт.
Править: URL находятся в формате/controller/method? аргументы. Как пример, на моем сайте, URL для/computer/article.php? идентификатор =# использует функцию статьи в компьютерном контроллере. Компьютерный контроллер, в свою очередь, использует модель статьи для загрузки данных в представление статьи с вложенными представлениями абзаца. Это также иллюстрирует, что даже при том, что предыдущая версия сайта имела названия страницы с .php расширением в URL, это может все еще перевести в метод класса контроллера, и те же работы URL в MVC основывали версию сайта. Это должно дать Вам и идее того, как Kohana мог бы работать на Ваш сайт.
В создании перемещения как это Вы только изменяете реализацию конкретного сайта, а скорее изменяете путь, которым это воспринято. Вы оказываетесь перед необходимостью вносить свою лепту перекодирования так или иначе, но Вы имеете преимущество понимания понятия и наличия опыта в том, как сделать это.
Мое предложение состояло бы в том, чтобы сесть и притвориться, что Вы ничего не знаете о том, как реализовать сайт, но все о том, какие проблемы связаны с видом сайта, Вы продолжаете работать - его требования и его глюки. Создайте основанное на MVC осмысление того, как сделать сайт и затем попытаться снова использовать как можно больше кода, который Вы имеете. Повторное использование кода не может в конечном счете быть выполнимым, но с другой стороны, по крайней мере, Вы решили многие из тех же проблем прежде, таким образом, оно не должно брать как долго для реализации.
Не забывайте, что можно всегда использовать маршрутизацию для поддержания разумной структуры URL для чего-то как ряд страниц формы с помощью различных контроллеров, позволяя Вам использовать различные контроллеры, действия и представления в то время как все еще способность одолжить у того же расположения или шаблона.
Какой смысл того, чтобы иметь одно представление на контроллер?
Снова:
- Вы не загружаете больше кода, чем необходимо на запрос. Вы загрузили бы библиотеку, пакет, dll, которого Вы не потребовали?Конечно, нет. Не создавайте крупный файл контроллера, где только небольшая часть кода будет выполняться на запрос. Кроме того, меньшие файлы легче поддержать imo, точно так же, как меньшие методы и модульный код.
- существует ясное 1:1 ссылка между контроллером и представлением (особенно, если они совместно используют то же имя). Это - конвенция. Это ясно и последовательно. Если я смотрю на шаблон представления, я знаю точно контроллер, который загружает базирующийся только на имени файла. Нет никаких включенных взглядов. Никакие решения. Никакие компромиссы.
Что потребность там для разделения проблем, когда все - просто подобранная пара?
Что потребность там для разделения проблем? Если Вы хотите к связанным с группой страницам (контроллеры/представления), смешиваете их в каталогах.
Я был бы более склонен записать контроллер, который управляет несколькими представлениями, которые связаны в некотором роде. Например, вышеупомянутые добавляют/просматривают/редактируют пользователя. Вы хотели бы держать схожую функциональность вместе вместо того, чтобы перерыть много файлов для кода, который Вы хотите. Также удобно иметь все определенные методы (для конкретного объекта) в одном месте. Делает обслуживание НАМНОГО легче.
Я собираюсь почтительно не согласиться. Если у меня есть единственное представление, которое ответственно за добавление/просмотр/редактирование пользователь, то с 1:1 конвенция я знаю точно ответственный контроллер. С другой стороны, с помощью предложения группировки схожей функциональности, если у меня есть контроллер менеджера и пользовательский контроллер, какой содержит добавление/просматривание/редактирование для менеджера? Пользователь или менеджер? Теперь необходимо думать, или поиск.
Я работал над проектом с помощью платформы PHP, которая создала отдельный файл на 'действие'. Названный как 'объект (действие)' и это стало КОШМАРОМ для поддержания.
Я не предлагаю это.
Я использовал Django на некоторое время теперь, который сохраняет все модели в одном файле, все представления (контроллеры) в одном файле и шаблоны (представления) отдельно. [Django не является MVC, но в этих целях, давайте притворимся, что это]. Это позволяет Вам группироваться, общий код в одном месте и обслуживании становится намного легче.
Я чувствую whoosy теперь. Я не знаю Django, и я предполагаю, что единственные файлы являются дополнительными, но нет никакого способа, которым я поддержал бы файл с десятками тысяч строк.
Мой единственный совет - не пытаются организовать Ваш проект на основе некоторого идеала MVC. Организуйте свой проект, как он имеет смысл Вам и Вашему домену.
Нет, нет, нет. Это - очень опасный совет. Шаблоны разработки, кодируя конвенции и платформы были разработаны для цели - лучшие практики и непротиворечивость. Только гуру должен ступить вне конвенций и только если он работает один. Даже в рамках ограничений платформы, я постоянно борюсь за большую непротиворечивость так, чтобы я не думал при записи или поддержании кода.
Если бы я понимаю Вас правильно, каждый контроллер произвел бы одну страницу. Это может быть действительно плохой идеей, что я испытал на собственном опыте в положении обслуживания.
Платформа "MVC" я имел дело с этим, сделала один контроллер для просмотра, быстро стал замысловатой путаницей с большим количеством взломов и запутанного кода.
Это было из-за платформы, разработчика или обоих? Как было трудно поддержать? Какие взломы были включены и почему?
1 контроллер к 1 представлению работает хорошо на меня в php MVC Зенд платформ, CodeIgniter и Kohana. В ASP.NET, хотя не MVC, 1 веб-форма/представление отображается на 1 коде позади файла.
У меня также все еще есть некоторые проблемы того, когда принять то решение использовать контроллер вместо действия. Хорошим примером был бы этот stackoverflow веб-сайт. В верхней части страницы у Вас есть выбор "Вопросов", который мы могли принять, берет Вас к контроллеру "вопросов". Я говорю это, потому что на правой стороне можно выбрать к тому, "Задайте вопрос", на который указывает URL, "подвергает сомнению/спрашивает". Таким образом, это имеет смысл что Ваше использование спросить метод контроллера вопросов.
Ну, мы не знаем, "спрашивают" ли, действие контроллера "вопросов". Этот сайт мог направлять, "подвергает сомнению/спрашивает" URL к другому контроллеру, или "спросите", мог быть контроллер в каталоге "вопросов". Кроме того, если Вы поднимаете, "подвергает сомнению/спрашивает" страницу, Вы заметите, что форма отправляется на, "подвергает сомнению/спрашивает/отправляет". Теперь "сообщение" могло быть параметром для "спросить" метода действия, но я предположу, что это - метод действия "сообщения" "спросить" контроллера.
Кто знает. Но рассмотрите это: страница "Questions" потребовала бы несколько раз большего количества кода, чем страница "Ask Question". Имело бы смысл загружать код страницы "Questions" при загрузке страницы "Ask Question". Я думал бы, что stackoverflow парни будут более умными, чем это.
Но то, что смущает меня, затем, у Вас есть опция "Unanswered" в меню. Похоже, что это имеет контроллер к себе. Почему это только не было бы действие под контроллером вопросов? Как в "вопросах / оставшийся без ответа"? Это - то, где вещи становятся грязными для меня.
Другая причина, почему я думаю страница "Ask Question", имеет свой собственный контроллер. Страница "Questions" имеет намного больше вместе со страницей "Unanswered".
То, где у меня есть большая часть проблемы, решает, когда на самом деле создать контроллер по сравнению с созданием чего-то просто действие, потому что это не всегда настолько ясно.
Везде, где возможно, используйте один контроллер на представление. Тот путь:
- Вы не загружаете больше кода, чем необходимо на запрос
- существует ясное 1:1 ссылка между контроллером и представлением (особенно, если они совместно используют то же имя).
Вся концепция была прояснена мне серией из трех сообщений в блоге Nemetral которые объясняют, как шаблон развивается из традиционного сценария веб-страницы и, таким образом, когда логика PHP становится отдельной от логики представления, то есть с точки зрения MVC, как модель становится отдельной от представления. According to Nemetral:
- The first step is to move all PHP code that was up to now coupled with HTML tags, to the head of the page.
- The second step is to move all HTML tags to a separate file and access it via a PHP include. So when a request is made it is directed to the PHP code (controller and model) and this code then requests the HTML tags or presentation (view).
I write more about this in my dissertation: http://kreus-cms.com/kreus/pages/written_work
Предположим, у вас есть какие-то тесты, охватывающие большую часть (все?) Функциональности вашего приложения.
- Изложите действительно базовую структуру того, как ваша C-часть будет выглядеть например.
- Реализуйте эту структуру, игнорируя M и V, более или менее просто копируя фрагменты кода из файлов, ориентированных на страницы, в ваши контроллеры
- Проверьте, что все по-прежнему работает должным образом. буквы «М» и «В». «M» может быть просто Active Record (я знаю, что это не настоящая модель) или шлюзом таблицы строк или чем-то, что довольно быстро реализовать. Контроллер теперь должен становиться все тоньше и тоньше.
- Проверьте, что все по-прежнему работает должным образом
- Теперь, когда вы знаете все о своем приложении, проведите рефакторинг снова, чтобы извлечь модель предметной области, если применимо. В некоторых случаях это может быть просто пустой тратой времени (только CRUD / интенсивные приложения)
- Убедитесь, что все работает должным образом.