我习惯于在Git中管理带有标签的版本。但是很久以前,对于独立应用程序而言。现在问题是我有一个Web应用程序,并且在同一个应用程序中可能会连接希望与应用程序的不同版本通信的客户端。
所以,我以这种方式为输入添加了一个路径变量:
@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
现在的问题是我有很多重复。
我也想解决这个问题。我现在该怎么做才能拥有一个以下的Web应用程序:
1) Deal with multiple versions
2) It is not messy (with a lot of conditions)
3) Doesn't have much duplication
答案 0 :(得分:1)
通常,当我们谈到旧版本的应用程序时,我们的意思是该版本的行为和外观是一成不变的,并且不会改变。如果您对该应用程序的源文件进行了最轻微的修改,那么它的行为和/或外观可能会发生变化(根据墨菲定律将更改),这是不可接受的
所以,如果我是你,我会将旧版本的所有源文件锁定在源代码库中,这样任何人都无法提交它们,永远。这种方法解决了这个问题并决定了你必须要做的其他事情:每个版本都必须拥有自己的一组源文件,这些源文件与所有其他版本的源文件完全无关。
现在,如果应用程序的旧版本必须与最新版本有一些共同之处,并且这个东西发生了变化(比如数据库),那么我们并不是在谈论不同版本的应用程序,我们有一些东西更类似于不同的皮肤:应用程序的核心发展,但不久前选择皮肤的用户可以坚持使用皮肤。在这种情况下,已经被其他人建议的多态解决方案可能是更好的方法。
答案 1 :(得分:0)
您的版本号位于名为“Context Root”的URL中。 您可以释放多个不同的WAR文件,每个文件都配置为响应不同的Context Roots。 所以版本1的战争,版本2的一场战争等。
这会让您重复代码。 所以你真正要问的是,“我如何有效地模块化Java Web应用程序?”。
这是一个很大的问题,并引导您进入“Enterprise Java”。 基本上,您需要通过将公共代码抽象到不同的应用程序来解决它。通常这称为“n层”设计。 因此,您需要创建一个“集成层”应用程序,您的“演示”层战争文件会对其进行说明。 Integration层包含所有公共代码,因此不会重复。
您的集成层可以是EJB或Web服务等。 或者您可以使用OSGi进行调查。