Каркасы для многоуровневых архитектур

Question

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

• Какую платформу вы рекомендуете для генерации Многоуровневых архитектур ?
• Исходя из вашего опыта, почему вы предпочитаете использование некоторых Framework вместо вашей собственной архитектуры ?
• Как долго вы полагаете, что выбранный вами Framework останется предпочтительным вариантом виндустрия разработки программного обеспечения?

Answer 1

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

Java

Java EE

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

Java EE на самом деле не заставляет вас использовать все его части, но вы выбираете то, что вам нравится.

Сверху он состоит из следующих частей:

Веб-слой

Для веб-уровня Java EE в первую очередь определяет компонент и основанную на MVC веб-платформу под названием JSF - JavaServer Faces. JSF использует язык описания представлений на основе XML (язык шаблонов), называемый Facelets. Страницы создаются путем определения шаблонов и предоставления клиентам шаблонов контента для них, включая другие лицевые стороны, и, наконец, размещения на них компонентов и общей разметки.

JSF предоставляет четко определенный жизненный стиль для выполнения всех действий, которые должно выполнять каждое веб-приложение: преобразование значений запроса, их проверка, обращение к бизнес-логике (модели) и, наконец, делегирование в представление (Facelets) для рендеринга. .

Для более подробного описания посмотрите некоторые статьи BalusC, например, Каковы основные недостатки Java Server Faces 2.0?

Бизнес уровень

Бизнес-уровень в инфраструктуре Java EE представлен облегченной структурой бизнес-компонента, называемой EJB - Enterprise JavaBeans. Предполагается, что EJB-компоненты содержат чистую бизнес-логику приложения. Среди прочего EJB-компоненты заботятся о транзакциях, параллелизме и при необходимости удаленном взаимодействии.

Обычный класс Java становится EJB с применением аннотации @Stateless. По умолчанию каждый метод этого компонента автоматически становится транзакционным. Это означает, что если метод вызывается и никакая транзакция не активна, запускается одна, в противном случае присоединяется одна. При необходимости это поведение можно настроить или даже отключить. В большинстве случаев транзакции будут прозрачны для программиста, но при необходимости в Java EE имеется явный API для управления ими вручную. Это JTA API - API транзакций Java.

Методы в EJB могут быть легко выполнены для асинхронного выполнения с помощью аннотации @Asynchronous.

Java EE явно поддерживает многоуровневую структуру через концепцию отдельного модуля специально для EJB. Это изолирует эти бобы и предотвращает доступ к их верхнему слою. Посмотрите это Упаковка EJB в JavaEE 6 WAR против EAR для более подробного объяснения.

Стойкость слоя

Для персистентности инфраструктура Java EE поставляется со стандартной платформой ORM под названием JPA - Java Persistence API. Это основано на аннотировании классов Java с помощью аннотации @Entity и свойства или поля для них с помощью @Id. При желании (при необходимости) можно указать дополнительную информацию посредством аннотаций о том, как объекты и отношения объектов отображаются в реляционной базе данных.

JPA сильно выделяет стройные объекты. Это означает, что сами сущности представляют собой как можно больше POJO, которые можно легко отправить на другие уровни и даже на удаленные клиенты. Сущность в Java EE обычно не заботится о своей собственной персистентности (то есть не содержит ссылок на соединения с БД и тому подобное). Вместо этого для работы с сущностями предоставляется отдельный класс EntityManager.

Наиболее удобный способ работы с этим EntityManager - внутри EJB-компонента, что делает получение экземпляра и обработку транзакций быстрым.Однако использование JPA на любом другом уровне, даже вне каркаса (например, в Java SE) также поддерживается.

---

Это наиболее важные службы, связанные с традиционными уровнями в типичном корпоративном приложении,но инфраструктура Java EE поддерживает множество дополнительных сервисов.Вот некоторые из них:

Обмен сообщениями

Обмен сообщениями напрямую поддерживается в инфраструктуре Java EE через API-интерфейс JMS - Служба сообщений Java.Это позволяет бизнес-коду отправлять сообщения в так называемые очереди и темы.Различные части приложения или даже удаленные приложения могут прослушивать такую ​​очередь или тему.

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

Рядом с JMS Java EE также предоставляет event-bus, которая представляет собой простую легкую альтернативу полноценному обмену сообщениями.Это обеспечивается через API CDI, который представляет собой комплексный API, который, помимо прочего, предоставляет области действия для веб-слоя и заботится о внедрении зависимостей.Будучи довольно новым API, он в настоящее время частично перекрывается с EJB и так называемыми управляемыми bean-компонентами из JSF.

Remoting

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

Если двоичное взаимодействие не поддерживается, Java EE также предоставляет различные реализации веб-служб.Это делается, в частности, с помощью JAX-WS (веб-сервисы, мыло) и JAX-RS (отдых).

Планирование

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

Эта часть Java EE применима, но, как уже упоминалось, довольно проста.

---

В Java EE есть еще кое-что, но я думаю, что это касается самых важных вещей.

Spring

Альтернативной корпоративной средой для Java является Spring.Это проприетарная, хотя и полностью открытая среда разработки.

Так же, как среда Java EE, среда Spring содержит веб-среду (называемую Spring MVC), среду бизнес-компонентов (просто называемую Spring или Core Spring Framework).) и стек веб-служб (называемый Spring Web Services).

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

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

Кроме того, Spring предлагает более тщательно и непосредственно используемый API безопасности (называемый Spring Security), в котором Java EE оставляет множество деталей по безопасности открытым для сторонних поставщиков.

Answer 2

Чтобы конкретно ответить на второй вопрос:

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

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

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

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

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

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

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

Answer 3

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

Для .Net существует Sharp Architecture , которая является довольно популярной средой для многоуровневых приложений.

Вот некоторые вещи, которые я использую (я не использую Sharp Architecture)

Во-первых, инфраструктура

• Для внедрения зависимостей я использую StructureMap . Я использую его, потому что он намного надежнее и эффективнее, чем все, что я хотел или мог бы написать, и очень хорошо поддерживается в сообществе .Net. Он также придерживается принципа DI и не рискует заниматься другими вещами, для которых я мог бы использовать другие библиотеки (AOP и т. Д.). Свободная конфигурация просто фантастическая (но у многих .Net DI Tools она есть)
• Для AOP я использую Linfu Dynamic Proxy . Я знаю многих людей, которым нравится разнообразие программных кодов по соображениям производительности, но это всегда казалось мне преждевременной оптимизацией.
• Для DataMapper я использую AutoMapper . Это тот, где я снова выключен. Если вы можете делать свои отображения, основываясь только на соглашении, тогда отлично, я буду его использовать. Как только мне нужно начать настраивать конфигурацию, чтобы делать особые вещи .... для меня это начинает попадать в серую область, где код может быть более четким, если использовать только функцию left => right, заключенную в функцию.

Web / UI

• Asp.Net MVC. Хотя, если честно, в последнее время у меня случаются ссоры, и, возможно, скоро я перейду к FubuMvc . Asp.Net MVC, похоже, разделил личность с точки зрения дизайна API (динамически здесь, статически там, using блоков для визуализации форм, но System.Actions для визуализации других вещей и т. Д.). Объедините это с тем фактом, что на самом деле это не OSS (вы не можете отправить патч), и для меня есть веская причина, почему сообщество должно придумать что-то лучшее, это OSS.

Настойчивость

• NHibernate, В частности Свободно NHibernate . Конечно, я хотел бы написать свой собственный OR / M, но в то же время я уверен, что толпы разработчиков, которые работали над NHibernate, намного умнее меня.

Услуги / Распределение и т. Д.

• WCF для синхронных вызовов
• NServiceBus для обмена сообщениями и большинства асинхронных вызовов.

Большая часть этого материала - OSS, так что, как долго это будет, ну, я бы вообразил довольно долго.

Answer 4

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

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

В настоящее время существует нет Доступные платформы, готовые для поддержки следующих краткосрочных потребностей предприятия:

• - переключение для большей части рабочей силы с ПК на планшет и телефон;
• - переключение с веб-клиента и rdbmsк p2p / отключен на основе хранения и распространения