Как должен быть структурирован весенний уровень представления MVC по сравнению с приложением Symfony2?

Чтобы лучше понять, чего я пытаюсь достичь, это изображение типичного Symfony2 приложение только с одним пучком и приложением пружины MVC рядом:

введите описание изображения здесь введите описание изображения здесь

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

Работа с Spring MVC напоминает работу с необработанным голым металлом. Я предпочитаю взвешенный подход. Я хочу иметь что-то похожее на связки в Symfony2 где каждый пакет содержит свои контроллеры, представления, формы, шаблоны, конфигурации, js и css. Я хочу, чтобы представления были сгруппированы по имени контроллера.

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

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

Я звучу так, словно искал фреймворк, построенный поверх Spring MVC (может быть, это решение в конце концов), но, возможно, у меня неправильный подход ко всему.

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

4

Решение

Прежде всего, я хочу сказать, что я создаю много php-приложений с помощью Symfony (не Symfony 2), поэтому в моих рассказах могут быть некоторые несоответствия, но я все равно могу поделиться своей точкой зрения.

Прежде всего, Symfony, как написано в php, является полной основой для всего. У него есть видение структуры папок (пакетов) не только потому, что он делает ваш код хорошо организованным … но и из-за технических ограничений php. Php в основном основан на инкрустации других источников php с помощью таких директив:

include ('/lib/somelib.lib.php');

Это единственный способ, которым php может загружать ресурсы. Это приводит к некоторым последствиям при написании фреймворков на php. Например, в Symfony, когда вы указываете свой браузер на http://localhost/some_module/some_url Symfony примет «по соглашению», что вы хотите загрузить контроллер с именем: some_module и вы хотите выполнить метод some_url в этом контроллере. На первый взгляд это звучит замечательно, но в этом есть одна «загвоздка». Symfony требует этого, потому что это единственный способ, которым Symfony может определить, какой контроллер и какой метод вы хотите загрузить (это, вероятно, аналогично в Symfony2). В противном случае вам нужно будет создать дополнительный файл конфигурации.

Java, с другой стороны, дает вам много способов для достижения этой цели без указания имени вашего контроллера и метода. Spring MVC просто использует то, что дает вам Java. В Spring вы можете дать любое имя вашему контроллеру и любое имя вашему методу. Вы можете достичь этого, например, используя аннотации для класса контроллера и метода:

@Controller
public class MyController {

@RequestMapping(value = "/some_module/some_url", method = RequestMethod.GET)
public ModelAndView searchForSomeData(@PathVariable("currentPage") String currentPageUrlString, @RequestParam("userId") Integer userId) {
(...)}

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

Другое дело, что Symfony (также из-за некоторых ограничений по созданию php-приложений) заставляет вас использовать собственный шаблонизатор в качестве технологии просмотра. Вот почему есть то, что вы назвали «группирование контроллеров по имени представления» (вы можете использовать другие механизмы для обработки представления, такие как Smarty, но это приносит боль). С другой стороны, в Spring вы не привязаны к какой-либо технологии просмотра. Ты можешь использовать Apache Tiles, JSP-страницы и все, что вы хотите. Вы просто настраиваете это и используете это. Более того, вы можете использовать две или более технологий представления в одном приложении — вам нужно только сообщить Spring, когда использовать одну технологию представления, а когда использовать другую (например, на основе префикса url). Конфигурация на удивление проста. Просто используйте аннотации, например, так:

@Configuration
public class WebConfig  {
@Autowired
@Qualifier("tilesViewResolver")
private ViewResolver tilesViewResolver;

@Autowired
@Qualifier("jstlViewResolver")
private ViewResolver jstlViewResolver;

@Bean
@DependsOn({ "tilesViewResolver", "jstlViewResolver" })
public ViewResolver viewResolver() {
Map<String, ViewResolver> resolvers = new HashMap<>();
resolvers.put("internal", jstlViewResolver);
resolvers.put("tilesView", tilesViewResolver);

ViewResolver globalViewResolver = new PrefixViewResolver(resolvers, jstlViewResolver);
return globalViewResolver;
}@Bean(name = "tilesViewResolver")
public ViewResolver tilesViewResolver() {
UrlBasedViewResolver url = new UrlBasedViewResolver();
url.setViewClass(TilesView.class);
return url;
}@Bean(name = "jstlViewResolver")
public ViewResolver jstlViewResolver() {
UrlBasedViewResolver resolver = new UrlBasedViewResolver();
resolver.setPrefix("/WEB-INF/internal/");
resolver.setViewClass(JstlView.class);
resolver.setSuffix(".jsp");
return resolver;
}
}

Итак, снова здесь Spring не заставляет вас использовать что-либо, потому что он не работает в среде с некоторыми ограничениями, такими как Symfony в php.

То же самое касается папки журналов и других. Вы не получаете папку журналов, потому что вам нужно объявить, какую технологию вы хотите использовать для входа в Spring / Java (будь то log4j, logback, commons logging, slf4j так далее). В symfony ваша папка logs определена по двум причинам. Во-первых, вы вынуждены (некоторые люди скажут «поощрено», но я предпочитаю называть его «вынужденным») использовать систему ведения журналов Symfony, которая по умолчанию настроена на использование каталога «logs» в каталоге вашего приложения. Во-вторых, снова возникают ограничения / характеристики php — при развертывании приложения php вы обычно сохраняете журналы в папке приложения, потому что у вас нет разрешения на запись в любую другую папку в файловой системе. При развертывании Java-приложения на Tomcat вы обычно сохраняете журналы в каталоге Tomcat или другом каталоге в файловой системе.

Таким образом, суть заключается в свободе. Вот почему вы не получаете никакого «стандарта» в Spring MVC в этой области. Вы создаете свой собственный стандарт, который соответствует вашему приложению.

4

Другие решения

Других решений пока нет …

По вопросам рекламы [email protected]