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

Question

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

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

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

10

architecture frameworks

Источник

user476200 18 дек '10 в 00:30

4 ответа

Решение

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

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

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

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

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

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

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

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

5

Источник

user472792 28 дек '10 в 18:45

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

Для.Net существует http://www.sharparchitecture.net/, которая является довольно популярной средой для многоуровневых приложений.

Вот некоторые из вещей, которые я использую (я не использую 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, так что, как долго это будет продолжаться, ну, я бы вообразил довольно долго.

1

Источник

user113702 28 дек '10 в 16:35

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

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

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

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

0

Источник

user35306 28 дек '10 в 09:37

Другие вопросы по тегам architecture frameworks

user472792 28 дек '10 в 16:03 2010-12-28 16:03 · Accepted Answer · 2010-12-28 16:03

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

Джава

Java EE

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

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

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

Веб-слой

Для веб-уровня Java EE в первую очередь определяет компонент и основанный на MVC Web Framework, называемый 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 через JMS API - Служба сообщений Java. Это позволяет бизнес-коду отправлять сообщения в так называемые очереди и темы. Различные части приложения или даже удаленные приложения могут прослушивать такую очередь или тему.

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

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

Remoting

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

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

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

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

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

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

весна

Альтернативным корпоративным фреймворком для 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 оставляет множество деталей безопасности открытыми для (сторонних) поставщиков.