Java, Компонентно-ориентированный по сравнению с основанными на запросе платформами
Полный NP класс проблем.
класс P состоит из тех проблем, которые разрешимы в [1 113] полиномиальное время . Например, они могли быть решены в O (n <глоток> k ) для некоторого постоянного k, где n является размером входа. Проще говоря, можно записать программу, которая будет работать в разумный время.
класс NP состоит из тех проблем, которые являются поддающиеся проверке в полиномиальное время. Таким образом, если нам дают потенциальное решение, тогда мы могли бы проверить, корректно ли данное решение в полиномиальное время.
Некоторыми примерами является булева Выполнимость (или SAT) проблема или проблема Гамильтонова цикла. Существует много проблем, которые, как известно, находятся в NP класса.
NP-Complete означает, что проблема [по крайней мере 1 118] настолько же трудно как любая проблема в NP.
Это важно для информатики, потому что было доказано, что любая проблема в NP может быть , преобразовал в другую проблему в полном NP. Это означает, что решением любой полной NP проблемы является решение всех проблем NP.
Много алгоритмов в безопасности зависят от того, что никакие известные решения не существуют для тяжелых проблем NP. Это определенно оказало бы значительное влияние на вычисление, если бы решение было найдено.
3 ответа
Скорее всего, они искали примеры веб- фреймворков - например, JSF является компонентом на основе запросов, а Struts - это структура на основе запросов.
Фреймворки на основе запросов обычно дают понять через свои API, что они « повторно работает с синтаксическим анализом запроса HTML / генерацией ответа HTML, в то время как структуры на основе компонентов пытаются абстрагироваться от этого и рассматривать приложение как коллекции компонентов с рендерерами и действиями для выполнения действий.
На мой взгляд, веб-интерфейс на основе компонентов фреймворки доставляют больше хлопот, чем они того стоят - их основная цель обычно состоит в том, чтобы «упростить» разработку веб-приложений для разработчиков, незнакомых с веб-разработкой, и приблизить их к традиционной настольной разработке. Однако на практике, когда что-то пойдет не так, вам необходимо разработать пользовательские компоненты, вам нужно настроить фреймворк для чего-то, что не является функциональностью «из коробки» и т. Д., Вам необходимо понимать как лежащие в основе «традиционные»
Фреймворк на основе запросов - это веб-фреймворк, который получает запрос пользователя, затем определяет, что система должна делать, и возвращает ответ пользователю. Таким образом, поток в значительной степени линейный. Вы думаете в действиях: что хочет пользователь (запрос) -> какой пользователь вернется (ответ). Примером инфраструктуры на основе запросов является Struts . Современный Grails в значительной степени тоже является фреймворком на основе запросов.
Компонентный фреймворк не такой. На самом деле нет четкого ощущения потока спереди назад. Примером этого является не JSF, потому что JSF в некотором роде почти такой же, как и Struts (поскольку создатель Struts и JSF один и тот же). Хороший пример компонентной структуры Tapestry и Wicket . Парадигма в этих двух рамках различна. Вы думаете не действиями или запросом-ответом, а компонентами и компонентами. Вы определяете компонент в своем приложении и сообщаете, что он делает. Но поток не обязательно должен быть линейным, как в структуре на основе запросов.
JSF - это компонентный Java API, как сказал Нейт, Struts - это структура, основанная на действиях, запросы Http анализируются, при обработке действий в конце сервлет контроллера перенаправляет запрос в JSP. который будет отвечать за создание ответа. В то время как в JSF, который стал стандартом для веб-фреймворков на основе компонентов, на самом деле нет необходимости обрабатывать запросы и ответы, поскольку все, что нам нужно, это написать страницы JSP или XHTML, привязать компоненты, используемые на странице, или значение, которое они должны отображать. к свойствам в резервных или управляемых bean-компонентах, а FacesServlet (контроллер) выполняет всю работу по синтаксическому анализу запроса и перенаправлению на JSP, который будет отображать ответ на основе правил навигации, указанных в faces-config.xml. Итак, как вы можете видеть, существует большая разница между Struts и JSF, поскольку JSF предлагает подход, основанный на компонентных событиях, в то время как Struts более близок к классической модели JSP / Servlet. Еще одна вещь, которую jpartogi сказал, что создатель JSF и struts - то же самое, я просто хочу упомянуть, что Struts - это фреймворк, принадлежащий сообществу Apache, а JSF - это API, указанный JCP в JSR-127 для версии 1.1 и JSR-252. для версии 1.2 и имеет различные реализации (SUN-RI, Apache MyFaces ...)