Выбор архитектуры

1

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

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

Помня все эти моменты, я бы сказал, что мне понадобится следующее

a) Я бы пошел на архитектуру уровня.

b) Для уровня представления: - может идти с JSP/servlets+JSTL или я должен идти с JSF

c) Для бизнес-уровня: - Spring MVC или EJB3.0?

d) DAO: - Hibernate/JDBC как слой DAO.

e) Database: - SQL-сервер или Oracle 10g.

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

Спасибо за вашу экспертную помощь заранее.

  • 2
    Этот вопрос, хотя мне лично они нравятся, обычно считается слишком широким и не по теме для переполнения стека. В любом случае то, что вы описали, может быть создано с использованием любой комбинации упомянутых технологий. То, что хорошо работает вместе или имеет лучшую поддержку, не является ответом на переполнение стека.
  • 0
    для, я думаю, вы имеете в виду «слой», а не «уровень». Уровень подразумевает распределенное приложение, в котором каждый уровень находится на отдельном хосте. варианты, перечисленные для b, кажутся ужасными c: «бизнес-уровень» не применим для Spring-MVC, вы имеете в виду просто весна? e: почему бы не открыть базу данных с открытым исходным кодом?
Теги:
architecture
hibernate

2 ответа

1

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

Прежде всего, просто хочу немного изменить ваши соображения:

  • b) Вы должны включить Spring MVC в эту точку, потому что это слой абстракции поверх сервлетов и может быть легко объединен с JSP. BTW Весенние парни в настоящее время предпочитают механизм моделирования шаблонов Thymeleaf, так что, возможно, что-то еще нужно учитывать. Вы также определенно хотите пойти в инфраструктуру безопасности, например Spring Security (не знаете, как она взаимодействует со стеклом Java EE)
  • c) Вероятно, вы захотите рассмотреть Spring IoC (Spring Core) и EJB3.0. Существует также система Google Guice.

Я бы предложил вам выработать свои решения по этим факторам

  1. Каковы ваши и ваши знания команды с определенными технологиями
  2. Какая у вас опыт работы с OPs (полнофункциональные серверы приложений Java EE или легкие контейнеры сервлетов, такие как Tomcat или Jetty)
  3. Ваш проект станет более крупным монолитом (посмотрите на преимущества полных серверов приложений Java EE) или набор микроуслуг (посмотрите на Spring Boot и преимущества, посмотрите также преимущества архитектуры архитектуры Microservices, а также PITFALLS ->, потому что это очень популярный архитектурный образец в настоящее время, но может привести к различным проблемам, таким как проблемы с производительностью или сложность производственной среды)
  4. Планируете ли вы использовать связанные с Spring проекты (например, семейство Spring Data для подключения к различным социальным сетям)
  5. Как вы думаете, вам нужно использовать наличные на сервере приложений (см. Hibernate с кешем второго уровня)
  6. JDBC vs Hibernate - это огромное архитектурное решение, поэтому лучше читать о плюсах и минусах. Если вы выберете JDBC, вы, вероятно, захотите перейти на Spring JDBC и, что наиболее важно, на какую-то платформу запросов, такую как JOOQ или QueryDSL.
  7. Если вы перейдете на Hibernate/JOOQ/QueryDsl, вы должны быть в безопасности, чтобы выбрать любую SQL-базу данных. Поскольку эти рамки абстрагируют различия, если вы избегаете использования пользовательских функций определенного поставщика. Сказал, что также важно взглянуть на ваш опыт OP и админов при выборе DB. Если вы хотите сэкономить деньги на лицензии, вы, вероятно, захотите взглянуть на PostgreSQL (DB с открытым исходным кодом предприятия)
  8. У вас есть некоторые архитекторы уровня предприятия, чтобы проконсультироваться с этими решениями. Уточните заранее, если ваше приложение должно быть интегрировано с более широкой корпоративной средой. В этом случае вы, вероятно, захотите взглянуть на Spring Integration или Apache Camel.
  9. У вас будет некоторая фоновая регулярная обработка, которая не запускается пользовательскими запросами? Взгляните на спецификацию Spring Batch/Java EE 7 Batch.
  10. САМЫЙ ВАЖНО СООТВЕТСТВУЕТ ВАШЕЙ КОМАНДЕ ОБ ЭТИХ РЕШЕНИЯХ, ЧТОБЫ ПРИВЛЕЧИТЬ СТАРШИЕ И ПАССАЦИОННЫЕ КОМАНДЫ. Вы не хотите слышать жалобы позже.
  11. Не бойтесь принимать окончательные решения. Отсутствие решения - БОЛЬШОЕ ХОЗЯЙСТВО, чем плохое решение.

(Я весенний парень, поэтому я извиняюсь, если этот звук, как ваше направление, должен быть весенним стеком. Стек Java EE определенно имеет альтернативы для большинства модулей Spring, поэтому сделайте свое собственное глубокое исследование).

0

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

  1. n-level архитектура - определенно - службы UI/REST/хранилище данных
  2. Уровень представления - я бы рекомендовал использовать библиотеку Javascript с открытым исходным кодом, такую как Prime NG. Дает вам возможность создавать отличные интерфейсы и в том числе и с помощью сервиса REST
  3. Бизнес-уровень - сервисы REST с Spring Boot или услуги REST REE 7. Я бы держался подальше от EJB. Использование REST даст вам возможность перейти на микросервис завтра
  4. DAO - Руки вниз JDBC или очень тонкая обертка над JDBC для меня. Спящий режим, на мой взгляд, только усложнит ситуацию и способность масштабировать. Хорошо спроектированная реализация JDBC будет превосходить Hibernate plus, а также предоставит вам возможность отделить оптимизацию
  5. База данных - если стоимость не является проблемой Oracle 10G. Нет никакого сравнения с Oracle, когда речь заходит о РСУБД. Обратите внимание, что они не являются открытым исходным кодом. Если вы хотите пойти с открытым исходным кодом, Postgresql/MySQL также может быть рассмотрен. Здесь я также рекомендую вам посмотреть варианты noSQL, такие как MongoDB/Couchbase

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

  • 0
    Извиняюсь, но видел, что это было опубликовано 3 года назад. Думал, что это недавно. В этом случае хотелось бы услышать, что вы наконец-то реализовали. Благодарю.

Ещё вопросы

Сообщество Overcoder
Наверх
Меню