Улучшить жизнь, не используя веб-рамки Java?

Мне так надоело изучать еще одну веб-инфраструктуру Java через день.
JSP, Struts, Wicket, JSF, JBoss Seam, Spring MVC, чтобы назвать лишь некоторые из них - все эти бесчисленные фреймворки пытаются решить те же проблемы. Тем не менее, ни один из них не решает основные проблемы - почему все еще все больше появляются новые и новые.

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

Короче говоря, я вижу следующие недостатки при использовании рамки:

В основном есть крутая кривая обучения, и сначала вам нужно понять, порой, достаточно академические концепции и знать смысл и расположение кучи конфигурационных файлов, прежде чем вы сможете начать.
Документация обычно более или менее ужасная, либо отсутствует общедоступная доступная онлайн-ссылка, является беспомощной устаревшей, смущает разные несовместимые версии или все это вместе и часто не дает никаких полезных примеров.
Структура состоит из циллионов классов, что делает практически невозможным понимание предполагаемого использования только при просмотре источников.
Поэтому вам нужно купить несколько "XYZ в действии для манекенов за 21 день", которые имеют плохой пользовательский интерфейс, потому что им не хватает полнотекстового поиска и тяжело переносить.
Чтобы действительно использовать одну из этих фреймворков, вам нужно научиться наизусть, как все может быть сделано так, как этого требует инфраструктура, запоминая адекватные классы и имена методов, пока ваша голова не будет наполнена глупой и бесполезной информацией, которую вы не можете использовать для чего-либо еще.
Есть большие накладные расходы, замедляющие производительность ваших приложений и заставляя ваш мозг чувствовать себя онемевшим, когда пытаетесь понять, что на самом деле происходит.
В реальном мире обычно нет времени, чтобы хорошо познакомиться с чем-то новым из-за давления быть продуктивным. Как следствие этого обучения, делая подход, вы всегда смотрите только на самый быстрый способ выполнить следующую задачу, а не понимать новый инструмент и возможности.
Аргумент о том, что по стандарту позволит людям, которые являются новыми для быстрого запуска проекта, недействителен в моем представлении, потому что каждый проект использует другую структуру даже в пределах одной компании (по крайней мере, в моем случае).

Мне кажется, что следующая цитата из Альберта Эйнштейна здесь очень хорошо подходит:

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

Вернувшись в старые добрые времена программирования PHP, когда кодирование по-прежнему было забавным и продуктивным, я использовал для написания своих собственных фреймворков для большинства вещей и просто скопировал их и перенял их из одного проекта в другой. Такой подход очень хорошо зарекомендовал себя, что привело к быстрой разработке, отсутствию накладных расходов и структуре, которая на самом деле была более сильной, чем большинство инфраструктур Java, но с несколькими сотнями строк кода в одном файле плюс некоторые простые правила mod_rewrite.
Это, безусловно, не решает все проблемы веб-разработки, но это было просто, быстро и прямо. Несмотря на то, что он был полностью адаптирован к требованиям текущего проекта, он также был легко расширяемым и имел очень высокую производительность из-за нулевой накладной.

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

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

Ответ 1

Вот цитата из Kev из потока Какое ваше противоречивое мнение по программированию? вписываются здесь очень хорошо:

Я думаю, что вся инфраструктура "Предприятие" - это дым и зеркала. J2EE,.NET, большинство инфраструктур Apache и большинство абстракций для управления такими вещами создают гораздо большую сложность, чем они решают.

Возьмите любые обычные Java или .NET OMR или любую предположительно современную среду MVC для того, что делает "волшебство" для решения утомительных простых задач. Вы в конечном итоге пишете огромное количество уродливого шаблона XML, который трудно проверить и быстро записать. У вас есть обширные API-интерфейсы, в которых половина из них предназначена для интеграции работы других API-интерфейсов, интерфейсов, которые невозможно перерабатывать, и абстрактных классов, которые необходимы только для преодоления негибкости Java и С#. Нам просто не нужна большая часть этого.

Как насчет всех разных серверов приложений с их собственным синтаксисом дескрипторов, сложной базой данных и продуктами групповой работы?

Точка не в том, что сложность == плохо, это лишняя сложность == плохо. Я работал в крупных корпоративных установках, где некоторые из них были необходимы, но даже в большинстве случаев для создания большинства случаев использования требуется несколько домашних сценариев и простой веб-интерфейс.

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

Ответ 2

Вернусь в старые добрые времена программирования PHP когда кодирование все еще было забавным и продуктивный, я писал свои собственные рамки для большинства вещей и просто копировать и вставлять их из одного проект к следующему. Этот подход очень хорошо оплачивается, что приводит к быстрому разработки, никаких накладных расходов вообще и рамки, которые на самом деле были сильнее чем большинство инфраструктур Java там

Простите, что я верю, что не одну секунду.

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

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

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

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

каждый проект использует разные рамки даже в пределах одной компании (по крайней мере, в моем случае)

Хорошо, это ваша проблема прямо там. Почему вы выбрали опыт, полученный в каждой структуре после каждого проекта?

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

Ответ 3

Проблема с созданием собственных фреймворков заключается в том, что вы будете совершать все те же ошибки, что и все установленные структуры уже наткнулись и обратились. Это верно, особенно в том, что касается безопасности.

Просто спросите Джеффа и парней о том, что им нужно было учитывать при реализации ОМП в переполнении стека. Я предпочел бы использовать то, что они произвели в проекте, а не реализовать его с нуля. Это всего лишь один пример.

Ответ 4

Проблема, конечно, не только с фреймворками Java. Я потерял подсчет количества проектов С++ MFC, которые я видел, барахтаясь, пытаясь обучить свои требования в модели Document/View (которая действительно работает только для текстовых и графических редакторов - приложениям баз данных особенно сложно обучить).

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

Ответ 5

Так вы говорите, что мы должны заниматься сокетами и HTTP каждый раз, когда хотим создать веб-приложение!

Сам контейнер сервлета можно рассматривать как фреймворк, поскольку он обрабатывает все эти беспорядочные детали и оставляет вам писать гораздо более простые сервлеты/фильтры/прослушиватели (т.е. "расширения" фреймворка, специфичного для вашего приложения).

Любая другая фреймворк пытается сделать, это отдельный обыденный, повторяемый, подверженный ошибкам, код legwork из веселого кода приложения.

Однако для небольшого приложения вы можете уйти просто с помощью Model 2 MVC, который использует только JSP и сервлеты.

Пример:

class MyController extends HttpServlet {
    public void doGet(HttpServletRequest request, HttpServletResponse response) throws ... {
        MyBean model = // do something
        request.setAttribute("model", model);
        request.getRequestDispatcher("/view.jsp").forward(request, response);
    }
}

Затем, когда ваше приложение станет более сложным, вы можете посмотреть на использование Spring MVC, чтобы обеспечить более легкое соединение (и, следовательно, более гибкое) контроллеров, просмотр разрешителей и т.д.

Ответ 6

Я разделяю вашу боль, когда сталкиваюсь с еще одной структурой, которая не делает трюка.

Прожив за десять лет jsp, struts, EJB, EJB2, struts2, jsf, а теперь и все новые фреймворки веб-сервисов, ужасы xslt и первые кошмары wsdl, я определенно устал.

Существует ряд проблем с фреймворками. Они leak, поэтому вам нужно узнать больше - не говоря уже о том, что внутренние структуры имеют огромные издержки, используя внешние затраты на инфраструктуру (но гораздо меньше), поскольку они редко доставляются, а затем вы в конечном итоге пишете enourmus куски xml-конфигурации и тратите дни на исправление ошибок и орфографических ошибок, которые вы сразу заметили в своем любимом контенте, помогая редактору кода.

Возможно, ответ заключается в том, чтобы найти менее напыщенные инструментальные средства, которые пытаются решить проблему, но не переопределяют мир, но это тоже сложно, поскольку основная модель приложения (html over http) неудобна - в лучшем случае.

Добавьте тот факт, что, кажется, существует много complicators, люди, которые, похоже, одержимы торговыми скучными простыми проблемами к сложным (но сложным) проблемам (возможно, варианту аксиомы Эрика Сникса, упомянутому выше).

Добавьте высокомерие разработчиков, которые все это знают, и не стесняйтесь писать новую фреймворку, чтобы решить все трудные проблемы для вас. Только они не могут, оставив 10% слева, гораздо сложнее исправить сейчас.

У меня нет опыта .NET, но мир .NET, кажется, меньше переполнен теоретиками и компиляторами, и, возможно, затяжная вонь VB отпугивает их, но каждый раз, когда я слышу, что кто-то говорит мне, что они потратили 1500 часов на их maven config (привет?), я серьезно подумываю об удалении "java" из моего резюме.

... в чем вопрос снова? Существуют ли какие-либо рамки, которые имеют значение?

EDIT - добавлены Stripes и QueryDSL.

Я бы попробовал Stripes или GWT с QueryDSL + Hibernate или OpenJPA (с аннотациями) только для того, чтобы вы действительно развивались на Java и пытались ограничить использование wsdl-первых веб-сервисов, xml-ориентированных фреймворков, EJB и ESB (а не пиво) как можно больше.

Ответ 7

Ну, не каждый день то же самое скучно...?

Ответ 8

Мне приходилось работать над проектом, пытающимся реализовать его в JSF. Это был кошмар.

Большая часть рабочего времени была потрачена на то, чтобы просто скомпилировать вещи. Дело в том, что не менее половины того, что было скомпилировано, не работало, это была другая история. Практически нет учебников. Документация - это в основном автоматический экспорт исходного кода без комментариев. Как можно ожидать, что это будет работать?

Из нескольких фреймворков, которые мы видели, только Sun смогла создать новый проект, который компилируется вообще! Другой может производить только кучу вещей, которые потребовались много дней, чтобы позвонить в компилируемое состояние.

Сеть была почти бесшумной. Для любого поиска мы получаем не более 20 страниц результатов поиска, с полезными первыми 1-3. В том, что было уместно, что было найдено, половина людей плакала о помощи, другая половина заявила, что они кричали о помощи, никто не пришел, они потеряли время и интерес и отказались от этой технологии.

Итак, мы провели время и сделали только что-то простое, что можно было сделать через несколько недель с помощью ASP.NET.

Затем мы рассмотрели альтернативные рамки JSF. К нашему удивлению, мы обнаружили, что все они совершенно несовместимы.

Не удивительно, мы присоединились к рядам тех, кто также сбросил JSF.

Ответ 9

Рассмотрим встречную точку. Я сейчас работаю в магазине, который не использует никаких фреймворков за пределами стандарта JSP. У всех есть разные способы делать вещи, и мы очень слабо разбираемся в таких концепциях, как де-мутация и проблемы безопасности, такие как проверка.

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

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

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

Ответ 10

Что сработало для меня, так это: вы не должны просто изучать любую веб-структуру, о которой вы слышали, взгляните на нее, посмотрите, удобно ли это сделать код, спросите о stackoverflow или форумах, чтобы увидеть его преимущества и недостатки, а затем изучите это и учиться этому хорошо и просто придерживаться его, пока вы не почувствуете его сломанный или простой устаревший. Любая из веб-страниц, о которых вы писали, хороша сама по себе и с удовольствием работает, если вы "ДЕЙСТВИТЕЛЬНО" знаете, что она делает. если вы этого не сделаете, вы просто блуждаете в пустыне без компаса! Я также нашел, что 21-дневная книга - это верный способ для вас НЕ овладеть каркасом или технологией. Документы, безусловно, что-то нужно учитывать при принятии f/w, это также помогает, если вы посмотрите вокруг кода самостоятельно (на самом деле это то, что помогает мне лучше, когда я сталкиваюсь с каким-то поведением, которое я нахожу странным.

1-Так почему все, что хлопот с использованием этих фреймворков, почему бы не выбросить их всех и вернуться к корням?

если вы вернетесь к корням, которые вы переписываете код, который делает то же самое снова и снова +, большинство из этих f/ws являются открытыми исходными текстами, значит, они, вероятно, лучше обслуживаются, чем вы сделали бы самостоятельно с вашим f/w.

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

Это мой первый опыт работы с этим f/w. Я не понимаю, почему мы должны использовать этот f/w, который я уже знаю X, и я действительно хорош в этом. не говоря уже о том, как мне узнать об этом f/w, стоимости переделки, которая должна быть сделана из-за моего незнания такого f/w. Я думаю, нам лучше использовать X, если это конкретное требование, мы должны бороться за него и делать это только в том случае, если нам действительно нужно указывать предыдущие заметки.

Или могут быть рамки, которые действительно влияют?

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

Или некоторые скрытые преимущества, которые я проигнорировал?

не может думать ни о каком tbh.

Ответ 11

У вас такая же проблема в PHP: больше фреймворков, чем у вас есть пальцы, чтобы подсчитать их, причем каждый из них является лучшим и самым большим (хотя у вас есть несколько советов: чистый дизайн PHP5 против совместимости с PHP4, философия Rails (негибкая иерархия папок, автоматически сгенерированный код) против библиотечного подхода...), и вы тратите больше времени на поиск и изучение возможностей, чем написание кода!
Но в PHP он позволяет заранее решить общие проблемы, такие как поддержка I18N, интеграцию плагинов, управление сеансами и аутентификацию, абстракцию базы данных, шаблоны, поддержку Ajax и т.д. Избегайте повторно изобретать колесо по каждому проекту и падать в общих ловушках для новичков.

Конечно, есть и некоторые подсказки для фреймворков Java: большие или малые? хорошо документированы или нет? широко используется или конфиденциально? для поклонников XML или нет? Etc.
Я полагаю, что большинство фреймворков нацелены на крупные проекты, где время обучения не является большой проблемой, важны масштабируемость и простота развертывания и т.д. Вероятно, они слишком малы для небольших проектов.

Существует также тенденция в таких рамках, направленная на то, чтобы сделать последовательный набор свободно связанных библиотек скорее монолитной структурой. Это случай, в мире PHP, для рамки Zend (некоторые даже отрицают использование слова "framework"...).
Поэтому он решает проблему "решения общих проблем", не мешая им.

Ответ 12

Однако я не согласен с некоторыми моментами, которые вы упомянули, но я согласен с вами в отношении скучной работы.

Да, все веб-приложения относятся к страницам, отображающим формы, собирающим данные, выполнению проверки, отправке данных для хранения в базе данных и фильтрации сохраненных данных формами поиска и отображению результата в таблицах и выбору одной или нескольких записей для манипуляции ( CRUD или бизнес-действия, касающиеся изменения статуса в базе данных).

однако я работаю всего 4 года плюс, конечно, свое 4-летнее академическое исследование. Я чувствую, что этот тип развития скучен, поскольку вы не изобретаете алгоритмы, конечно, вы были счастливы, когда открываете новую инфраструктуру и будете счастливее, если бы вы интегрировали один из двигателей AI в свое приложение, но в конце я чувствую, что эта работа это фиктивные работы или позволяет говорить о работе машины, поэтому почему мы не автоматизируем все это.

да еще одна фреймворк;) Архитектура, управляемая моделью MDA, вкратце рассказывает о преобразовании из PIM (независимой от платформы модели) в PSM (специфичная для платформы модель), например, от UML к коду.

И это может решить вашу проблему с кривой обучения и технологией, поскольку вам нужно будет только хорошо моделировать, так как есть несколько фреймворков, которые реализуют спецификации MDA, такие как AndroMDA, поскольку у него есть картриджи, которые принимают диаграммы классов, примеры использования, диаграммы последовательности и диаграммы действий и генерируют создание базы данных script, POJOs, сопоставление гибернации, Spring/EJB, JSF/Struts, код .NET.

Конечно, такие рамки не будут генерировать 100% кода, но будут генерировать большой процент, и, конечно же, вы спросите, где эта структура будет решать сложные и сложные сценарии требований? сегодня я скажу нет, завтра да.

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

Ответ 13

Итак, вы думаете, что лучше, если мы все изобретаем колесо в каждом проекте?

Вы можете увидеть избыток фреймворков как проблему, и это затрудняет выбор вашего собственного набора. Но, с другой стороны, вам не нужно попробовать каждый; и даже если вы это сделаете, вы в конечном итоге предпочтете некоторые из них. У вас будет любимая структура для ORM, другая для веб-разработки, IoC и т.д.

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

Плюс, использование фреймворка вместо написания собственных поможет вам сэкономить массу проблем. Ошибки не всегда обнаруживаются и решаются авторами; которые часто выполняются пользователями структуры. Вы сказали, что закончили с вашей собственной частной картой в PHP; Уверен, что это не было ошибкой, но, возможно, вы не знали об этом, так как вы были единственным пользователем и единственным кодером.