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

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

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

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

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

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

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

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

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

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

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

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

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

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

So are you saying we should deal in sockets and HTTP every time we want to build a web application!

The servlet container itself can be considered a framework, since it handles all these messy details, and leaves you to write much simpler Servlets/Filters/Listeners (ie: 'extensions' of the framework specific to your application).

All any framework tries to do is separate mundane, repeatable, error-prone, legwork code from the fun application-specific code.

However, for a small application, you can get away with simply having a Model 2 MVC approach which uses only JSPs and Servlets.

Example:

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);
    }
}

Then as your app becomes more sophisticated, you could look at using Spring MVC to provide looser coupling (and hence more flexible) of controllers, view resolvers etc..

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

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

Существует ряд проблем с фреймворками. Они пропускают , так что вам нужно учиться больше, а не меньше, у внутренних платформ есть огромные затраты, использование внешних плат тоже стоит (но гораздо меньше), поскольку они редко доставляют, и тогда вы в конечном итоге пишете огромные куски XML -конфигурировать и тратить дни на исправление падежных и орфографических ошибок, которые вы видели сразу же в своем любимом контенте, помогающем редактору кода. и, может быть, затянувшаяся вонь VB отпугивает их, но каждый раз, когда я слышу, как кто-то говорит мне, что они потратили 1500 часов на свою конфигурацию maven (привет?), я серьезно думаю об удалении «java» из моего резюме.

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

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

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

из моего резюме.

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

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

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

из моего резюме.

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

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

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

Ну, разве каждый день не бывает скучно ...?

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

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

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

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

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

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

Совершенно неудивительно, что мы присоединились к числу тех, кто бросил JSF.

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

да еще одна структура;) Вкратце, MDA Model Driven Architecture - это преобразование из PIM (независимой от платформы модели) в PSM (специфичной для платформы модели), то есть, например, из UML в Code.

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

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