Сделать жизнь лучше, не используя веб-фреймворки Java? [закрытый]

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

Простите меня за то, что я поверил в это не одну секунду.

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

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

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

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

Ну, это твоя проблема. Зачем тебе выбрасывать приобретенный опыт? с каждым фреймворком после каждого проекта?

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

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

просто спросите Джеффа и ребят о том, что они должны были учитывать при реализации WMD в Stack overflow. Я бы предпочел использовать то, что они создали в проекте, а не реализовывать его с нуля. Это только один пример.

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

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

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

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

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

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

пример:

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 для обеспечения более свободной связи (и, следовательно, более гибкой) контроллеров, резольверов и т. д..

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

пережив десять лет jsp, struts, EJB, EJB2, struts2, jsf и теперь совсем недавно все новые веб-сервисы framworks, ужасы xslt и кошмары WSDL-first, я определенно сыт по горло.

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

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

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

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

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

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

изменить - добавлены полосы и QueryDSL.

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

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

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

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

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

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

затем мы рассмотрели альтернативные фреймворки JSF. К нашему удивлению, все они оказались несовместимыми.

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

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

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

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

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

Что сработало для меня: вы не должны просто изучать любую веб-структуру, о которой вы слышите, взглянуть на нее, посмотреть, удобно ли она делает вас кодом, спросить вокруг stackoverflow или форумов, чтобы увидеть ее преимущества и недостатки, а затем изучить ее и узнать ее хорошо и просто придерживаться ее, пока не почувствуете, что она сломана или просто устарела. Любой из веб-фреймов, о которых вы писали, хорош сам по себе и забавен, если вы "действительно" знаете, что он делает. если нет, то ты просто блуждаешь в пустыне, где нет ... компас! Я также обнаружил, что книга "21 день" - это верный способ не осваивать фреймворк или технологию. Docs, безусловно, что-то рассмотреть при принятии f/w это также помогает, если вы посмотрите вокруг кода самостоятельно (на самом деле это то, что помогает мне лучше всего, когда я столкнулся с некоторым поведением, которое я нахожу wierd.

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

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

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

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

или, может быть, есть рамки, которые действительно имеют значение?

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

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

Не могу придумать никакого tbh.

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

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

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

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

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

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

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

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

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

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

да еще один фреймворк ;) СРЕДНЕСРОЧНАЯ ОЦЕНКА Архитектура, управляемая моделью, вкратце о преобразовании из PIM (независимая от платформы модель) в PSM (специфичная для платформы модель), i.e например, из UML в код.

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

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

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