Как создавать и архивировать веб-приложение Java/Java EE?

Я разработчик Java с почти 5-летним опытом работы на Struts, Spring и Hibernate.

У нас появился новый проект за несколько дней. У нас есть полные требования к нам, и мы будем делать этот проект, используя Spring MVC, Spring и Hibernate.

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

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

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

Ответ 1

Я могу добавить свои 2 цента из своего собственного опыта (хотя это скорее компиляция лучших практик разработки, вам может показаться полезным запомнить их при разработке вашего приложения):

Дизайн без единого размера
Постарайтесь сохранить приложение как можно более легким.
Используйте Maven/Gradle для управления зависимостями
- Не слишком полагайтесь на IDE. Убедитесь, что ваш проект построен без IDE (если вы используете maven/ gradle, он будет:) Попробуйте открыть проект с помощью IDEA, Netbeans и Eclipse.
Для технологий, упомянутых выше, appfuse делает хорошую отправную точку.
Сначала создайте свою базу данных/сущности.
Используйте библиотеки разумно и разумно. НЕ используйте их.
Не забудьте написать JUnit/TestNG (по крайней мере, для уровня обслуживания).
Тестировать приложение на всех основных браузерах (а не только на вашем любимом).
Определите, сколько всего пользователей и сколько одновременных пользователей будет иметь ваше веб-приложение.
- Затем решите, нужно ли кэшировать или нет.
- вы будете использовать кластер серверов приложений или нет.
Выберите сервер приложений на основе его возможностей и, что более важно, "ваши потребности",
- Tomcat/Jetty абсолютно подходят для большинства случаев.
Избегайте использования каких-либо приложений app-server api
Использование JPA-интерфейсов/аннотаций, даже если использование спящего режима в качестве реализации JPA
Будьте осторожны при сопоставлении отношений в объектах. Решите, какие свойства и отношения будут загружаться лениво и которые будут загружаться с нетерпением.
При разработке приложения учитывайте безопасность приложений. Spring безопасность - отличный выбор.
Никогда не злоупотребляйте HttpSession. Не храните слишком много в нем.
Сохранять сущности Serializable. Принудительные разработчики использовать toString(), hashCode() и equals()
Не забудьте использовать контроль версий с первого дня.
Не считайте, что spring/hibernate/spring -mvc будет лучшим выбором для вас. создайте небольшое доказательство концепций с параметрами от 3 до 4.
Попробуйте автоматизировать интеграцию/сборку/развертывание с помощью инструментов CI, таких как Jenkins
Проверять и настраивать SQL, сгенерированные Hibernate (время от времени)
Не позволяйте бизнес-логике проникать в слой вида. Hate jsp scriptlets? Рассмотрим скорость /Freemarker. JSP - не единственный вариант.
Внешняя настройка среды с помощью Spring PropertyPlaceholderConfigurator.
Если возможно, попробуйте интегрироваться с существующим механизмом аутентификации пользователя (например, LDAP/OpenID), а не писать самостоятельно. Это избавит вас от переосмысления колеса и ваших пользователей от запоминания еще одного набора имени пользователя и пароля.

Ответ 2

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

Методология

Используемая вами методология повлияет на то, какие задачи вы выполняете в первую очередь. Waterfall - популярная, но устаревшая методология. Более новая методология - это Agile, которая имеет несколько лиц. Мой любимый Scrum Agile для разработки программного обеспечения любого размера.

Диаграмма

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

Documentation

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

Ответ 3

Просматривайте сайт Agile Modeling, который подталкивает к "простому" моделированию. У них есть отличные рекомендации, в том числе полный "гибкий процесс моделирования" от сбора требований к разработке/разработке.

http://www.agilemodeling.com/

http://www.agilemodeling.com/essays/amdd.htm

http://www.agilemodeling.com/essays/agileArchitecture.htm

http://www.agilemodeling.com/essays/agileAnalysis.htm

http://www.agilemodeling.com/essays/agileDesign.htm

Что касается инструментов, мне нравится Visual Paradigm. Это относительно недорого (по сравнению с другими инструментами). Существует множество бесплатных инструментов для моделирования (google - ваш друг), но ни один не сравнивается с Visual Paradigm, а для бит, который он стоит, он того стоит. Если бы мой работодатель не подсчитал наличные деньги, я бы сам его купил...:)

Ответ 4

Взгляните на Роберта Мартина (он же дядя Боб) "Чистая архитектура". Вот быстрый обзор. Используя этот подход, вы сможете более подробно отложить такие детали, как Spring или Hibernate, и больше сосредоточиться на бизнес-логике. Или даже перейти от Spring к Java EE, не касаясь вашей бизнес-логики и приложения. Вы также получите тестовое приложение, которое будет соответствовать принципам SOLID, без особых усилий.

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

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

Ответ 5

подробнее

Прежде чем приступать к кодированию, снимите бизнес-требования. Создайте полный список запрошенных функций, примерные снимки экрана (если есть), диаграммы использования, бизнес-правила и т.д. В качестве документа функциональной спецификации. Это этап, на котором бизнес-аналитики и разработчики будут задавать вопросы о требованиях к пользовательскому интерфейсу, требованиях интеграции уровня данных, вариантах использования и т.д. Также расставьте приоритеты функций на основе бизнес-целей, сроков выполнения и итераций, необходимых для реализации.
Подготовьте документ технической спецификации на основе функциональной спецификации. Документ технической спецификации должен охватывать: Цель документа: например. В этом документе особое внимание будет уделено функциональности обслуживания клиентов. Обзор. Этот раздел в основном охватывает справочную информацию, область охвата, любые включения и/или исключения, ссылочные документы и т.д. Основная архитектура: обсуждает или ссылается на документ базовой архитектуры. Ответы на вопросы, как это будет масштаб? Можно ли улучшить эту производительность? Является ли он расширяемым и/или ремонтопригодным? Есть ли проблемы с безопасностью? Опишите вертикальные срезы, которые будут использоваться в ранних итерациях, и понятия, которые должны быть подтверждены каждым срезом. И т.д. Например, какие модели MVC [model-1, model-2 etc] следует использовать? Должны ли мы использовать Struts, JSF и Spring MVC и т.д. Или создавать собственную структуру? Должны ли мы использовать бизнес-делегата, чтобы отделить средний уровень с клиентским уровнем? Должны ли мы использовать AOP (аспектно-ориентированное программирование)? Должны ли мы использовать инъекцию зависимостей? Должны ли мы использовать аннотации? Нужна ли нам интернационализация? И т.п. Предположения, зависимости, риски и проблемы: выделите все допущения, зависимости, риски и проблемы. Например, перечислите все риски, которые вы можете идентифицировать. Варианты проектирования для каждого ключевого функционального требования. Также обсудите, почему определенная альтернатива дизайна была выбрана над другими. Этот процесс будет поощрять разработчиков анализировать возможные альтернативы проекта, не переходя на очевидное решение, которое не всегда может быть лучшим. Логика обработки: обсудите логику обработки для уровня клиента, среднего уровня и уровня данных. При необходимости добавьте диаграммы технологических процессов. Добавьте любые условия предварительного процесса и/или условия после обработки. UML-диаграммы для передачи дизайна разработчикам, разработчикам решений, архитекторам и т.д. Обычно требуются диаграммы классов и диаграммы последовательности. Другие диаграммы могут быть добавлены для любых особых случаев. Диаграмма диаграмм состояния: полезно описать поведение объекта в нескольких вариантах использования Диаграмма деятельности: полезно для выражения сложных операций. Поддерживает и поощряет параллельное поведение. Диаграмма диаграмм активности и состояний полезна для моделирования рабочих процессов с многопоточным программированием. Диаграммы взаимодействия и последовательности: используйте диаграмму совместной работы или последовательности, если вы хотите посмотреть на поведение нескольких объектов в одном случае. Если вы хотите посмотреть на один объект в нескольких случаях использования, используйте диаграмму состояний. Диаграммы объектов: диаграммы объектов показывают экземпляры вместо классов. Они полезны для подробного объяснения некоторых сложных объектов, таких как выделение рекурсивных отношений. Перечислите имена пакетов, имена классов, имена баз данных и имена таблиц с кратким описанием их ответственности в табличной форме.
Подготовьте документ стандартов кодирования для всей команды, чтобы повысить согласованность и эффективность. Некоторые методы кодирования могут ухудшить производительность, например: Неправильное использование класса String. Используйте StringBuffer вместо String для интенсивных вычислений. Код в терминах интерфейса. Например, вы можете решить, что LinkedList - лучший выбор для какого-либо приложения, но позже решение ArrayList может быть лучшим выбором. Неверный подход Список ArrayList = новый ArrayList(); Правильный подход Список list = новый ArrayList (100); Установите начальную емкость коллекции соответствующим образом (например, ArrayList, HashMap и т.д.). Чтобы повысить согласованность, определите стандарты для имен переменных, имен методов, использования журналов, фигурных скобок и т.д.
Подготовьте документ и шаблоны для обзора всей команды. Давайте рассмотрим некоторые элементы, которые должны охватывать обзор кода: Правильное объявление переменной: например. экземпляр против статических переменных, константы и т.д. Проблемы с производительностью. Используйте ArrayList, HashMap и т.д. Вместо Vector, Hashtable, если нет проблемы безопасности потока. Проблемы с памятью: например. Неправильное создание объектов вместо повторного использования объектов и объединения объектов, а не закрытие ценного ресурса в блоке finally и т.д. Проблемы защиты резьбы: например. Классы Java API, такие как SimpleDateFormat, Calendar, DecimalFormat и т.д., Не являются потокобезопасными, объявление переменных в JSP не является потокобезопасным, хранение информации о состоянии в классе действия Struts или многопоточном сервлете не является потокобезопасным. Обработка ошибок: например. Исключение повторного выброса без вложенности исходного исключения, методы EJB не выбрасывают исключение EJB для системных исключений и т.д. Использование стандартов кодирования: не используя фреймворки, System.out используется вместо log4j и т.д. Проблемы с дизайном: повторное использование кода, отсутствие четкого разделения ответственности, недействительное использование наследования для повторного использования метода, сервлетов, выполняющих прямой доступ JDBC, вместо использования классов DAO (Data Access Objects), кода HTML в действиях Struts или классах сервлетов, сервлеты используются как служебные классы, а не как контроллер потока и т.д. Документация кода: например. Нет комментариев, нет файлов заголовков и т.д. Ошибки: например. Вызов setAutoCommit в транзакции, управляемой контейнером, двоичный ИЛИ "|" используется вместо логического ИЛИ "||", полагаясь на pass-by-reference в удаленных вызовах EJB, ResultSet не закрывается на исключениях, методы EJB не бросают EJBException для системных исключений и т.д.
Подготовьте дополнительные необязательные руководящие документы в соответствии с требованиями, которые будут разделяться командой. Это будет способствовать согласованности и стандартам. Например: Рекомендации по созданию среды разработки J2EE. Рекомендации по системе контроля версий (CVS, VSS и т.д.). Рекомендации по шагам развертывания, настройкам среды, ant целям и т.д. Рекомендации по моделированию данных (любые стандарты компании). Рекомендации по обработке ошибок. Рекомендации по дизайну пользовательского интерфейса. Документ по обзору проекта, Документ процесса разработки программного обеспечения и т.д.

Ответ 6

Я отредактировал новую книгу по Spring, Hibernate и Data Modeling, которая ответит на ваш запрос в аспекте дизайна веб-приложения Java EE. Обычно веб-приложение Java EE имеет 5 уровней - клиент, презентация, бизнес-сервис, доступ к данным и ресурс (сущность). В книге основное внимание уделяется тому, как разрабатывать и разрабатывать каждый из этих уровней, принимая примеры всех взаимосвязей моделирования данных с использованием Spring и Hibernate. В качестве загрузки предоставляется все веб-приложение, в котором вы найдете информацию об управлении каждой взаимосвязью сценария моделирования данных.

Посмотрите на простой автономный объект. Чтобы управлять сущностью, необходимо создать такие методы, как создание, чтение, обновление, удаление и поиск всех записей. Поэтому, если мы идем снизу вверх, создание сущности образует первый шаг. Затем мы рассмотрим репозиторий, в котором есть методы, описанные выше. Далее идет уровень обслуживания, а затем контроллер REST Spring, который основан на JSON. Остальная задача включает в себя кодирование страницы JSP и вызовы JQuery AJAX для контроллера REST.

Подробнее о книге здесь