Несколько версий в веб-приложении: дублирование или грязный код?

1

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

Итак, я добавил во входную переменную путь для версии таким образом:

@PathParam("version") String version

И клиент может указать версию в URL-адресе:

https://whatever.com/v.2/show

Затем через код я добавил такие условия:

if(version.equals("v.2") {
    // Do something
}
else if(version.equals("v.3") {
    // Do something else
}
else {
    // Or something different
}

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

MyClassVersion2.java
MyClassVersion3.java
MyClassVersion4.java

Проблема в том, что у меня много дублирования.

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

1) Deal with multiple versions
2) It is not messy (with a lot of conditions)
3) Doesn't have much duplication
  • 0
    Это похоже на вопрос для CodeReview (codereview.stackexchange.com), но даже тогда вам придется опубликовать больше кода, чтобы немного понять общую структуру calling different classes according to the version .
  • 0
    MyClassVersion родительский класс MyClassVersion с помощью методов общего MyClassVersion
Показать ещё 2 комментария
Теги:

2 ответа

1

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

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

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

Поделиться
0

ваш номер версии находится в месте в URL с именем "Context Root". Вы можете выпускать несколько разных файлов WAR, каждый из которых настроен для ответа на различные корни контекста. Итак, одна война для версии 1, одна война за версию 2 и т.д.

Это приведет к дублированию кода. Так что вы действительно спрашиваете: "Как я могу эффективно модулизовать веб-приложения Java?".

Это большой вопрос и приводит вас к "Enterprise Java". По сути, вам нужно решить эту проблему, абстрагировав свой общий код на другое приложение. Обычно это называется "n-уровневым" дизайном. Таким образом, вы создадите приложение "уровень интеграции", о котором говорят ваши военные файлы уровня презентации. Уровень интеграции содержит весь общий код, чтобы он не повторялся.

Ваш уровень интеграции может быть EJB или веб-сервисами и т.д. Или вы можете исследовать с помощью OSGi.

Поделиться

Ещё вопросы

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