Приложение, которое мы оцениваем, представляет собой веб-приложение, построенное с использованием весеннего и весеннего mvc с базой данных оракула.Является ли это трехуровневой архитектурой?
Каждое нажатие на браузер заканчивается вызовом базы данных.
Основная часть бизнес-логики в процедурах базы данных.
Ну, у вас есть три уровня -
Так технически ваше руководство является правильно, по крайней мере, для количества ярусов в приложении. Вы можете легко сделать аргумент о том, что они не следуют передовым методам, SQL - это ужасный язык для ведения бизнес-валидации.
На вашей второй точке невозможно определить, является ли это совместимым с SOA приложением, хотя я уверен мой первый рожденный не был. SOA довольно сложно, и вы спрашиваете 10 человек, что это такое, вы получите 15 ответов. Но, основываясь на вашем описании, я бы сказал, что система терпит неудачу в тестировании SOA в областях обнаружения, компоновки, автономности, абстракции и свободной связи. И в зависимости от того, как вы на это смотрите, контракт на обслуживание.
Вот вопрос для вас, что ваша организация думает, для чего нужна SOA?
Из информации, предоставленной вами, не следует, является ли это трехуровневым или ориентированным на обслуживание.
3 Уровень обычно означает слой пользовательского интерфейса/уровень обслуживания/уровень базы данных. У каждого есть свои обязанности. Сервис-ориентированная архитектура часто означает, что у вас есть отдельные развертываемые службы для выполнения различных функций в системе. Только ваши заявления не подтверждают или не опровергают ни определение.
Возможно, у вас больше похоже нарушение шаблона MVC, чем многоуровневого шаблона. В типичном приложении MVC бизнес-логика принадлежит коду контроллера, а не процедурам базы данных. Однако трехуровневое приложение обычно требуется иметь три уровня, уровень интерфейса, бизнес-уровень и уровень сохранения. И технически у них это есть. Поэтому я думаю, что, может быть, вам стоит утверждать, что они не следовали за MVC должным образом, и что в лучшем случае они имеют плохо реализованное трехуровневое приложение.
Вы также не предоставили достаточно подробностей, чтобы доказать, что он не использует сервис-ориентированную архитектуру (хотя, если это так, я был бы удивлен). SOA связана с тем, как связаны логические компоненты, составляющие бизнес-логику. Если они свободно связаны с вещами, которые могут быть подняты и опущены и заменены для разных реализаций поставщика, тогда у них будет SOA. Если существует жесткая связь, так что логические компоненты не могут быть легко отделены друг от друга, не вызывая серьезных обрывов, тогда они этого не делают.
Если у них есть большая часть их бизнес-логики, находящихся в процедурах базы данных, то они , вероятно, не имеют SOA, но вы никогда не знаете. Остальная часть их бизнес-логики действительно может следовать этой схеме.
Я был слишком суровым в оценке архитектуры трех уровней. Теперь я исправляюсь. Любое приложение, имеющее надлежащие места для UI-BL-Persistance, может претендовать на три применения шины. Если слишком много запросов к базе данных, это указывает на плохую реализацию. Wrt SOA я согласен с тем, что информации недостаточно. Все ответы получают мой голос, и, как правило, я выбираю только один. –
Да с пружиной и пружиной-mvc позволяет использовать три слоя. Но так как каждый вызов заканчивается в вызове базы данных, мне кажется, что средний уровень выполняет прокси-функцию. Эффективно мы смотрим на слой пользовательского интерфейса -> прокси-сервер [бизнес-уровень, доступ к данным] -> база данных oracle11g. Оказывается ли это по-прежнему претендовать на 3-мя шинами? Wrt SOA Я согласен, что существует множество определений. –
У вас все еще есть несколько уровней, но средний уровень интеграции просто * сильно * недоиспользуется. Это тонкая линия с этими уровнями, особенно при использовании архитектуры пользовательского интерфейса, которая может эффективно поддерживать интеграцию промежуточного программного обеспечения. До J2EE и Spring мы вставляли всю нашу промежуточную логику в сервлеты контроллера. Странно, да? Но да, я думаю, вы можете сделать аргумент своему руководству о том, что ваш уровень промежуточного уровня фактически накладные расходы, поскольку его так плохо недоиспользуется. – Perception