将 2 层 Java 应用程序迁移到...?

发布于 2024-09-17 11:27:10 字数 734 浏览 7 评论 0原文

目前,我们有一个位于 MS SQL Server 2005 之上的 2 层 Java Swing 应用程序。所有业务逻辑都在数据库中。客户端相当旧(而且不太友好),出于性能和可扩展性的原因,我们已经开始将一些服务移植到 Java 的中间层。

然而,我们仍然有许多短期和长期目标:

为新前端选择一个技术堆栈

这并不容易 - 我可以看到从连续体一端的 Web 应用程序到传统桌面应用程序的所有内容另一个是可行的选择。目前的前端并不是很复杂(主要是基于表单的),所以我可以看到 web/AJAX 的适配,但这是一个我们不知道我们不知道的领域。

我列表中的堆栈包括:

  • Eclipse RCP、Netbeans RCP
  • Flex/Flash、Silverlight、JavaFX
  • 纯 Javascript 前端(Sprout Core、Javascript MVC 等)
  • 基于 Java 的 Web 框架(Wicket、JSF 等

)使当前应用程序在远程情况下执行可接受的性能

我们有一些客户将我们的应用程序转售给较小的客户,并且需要能够远程部署它。由于当前体系结构的 2 层性质,这会导致糟糕的性能(例如,调用返回 18 个结果集的存储过程)。我们过去使用过 Citrix 解决方案,但没有人喜欢这种方法。通过端口 80 建立 JDBC 隧道听起来也不是一个好主意。我开始想知道是否有任何东西可以使用类似 X-Windows 的方法来远程控制 GUI 部分。

We currently have a 2-tier Java Swing application sitting on top of MS SQL Server 2005. All the business logic is in the database. The client is quite old (and not very friendly), and for reasons of performance and scalability, we've already started porting some services to a middle tier in Java.

However, we still have a number of short and long term goals:

Pick a technology stack for a new front-end

This isn't easy - I can see everything from a web app at one end of the continuum to a traditional desktop app at the other being viable choices. The current front-end isn't really complex (mostly form-based), so I can see web/AJAX fitting, but it's an area where we don't know what we don't know.

Stacks on my list are:

  • Eclipse RCP, Netbeans RCP
  • Flex/Flash, Silverlight, JavaFX
  • Pure Javascript frontends (Sprout Core, Javascript MVC, ...)
  • Java-based Web frameworks (Wicket, JSF, ...)

Find a way of making the current application perform acceptably in a remote situation

We have some clients who resale our app to smaller clients and need to be able to remotely deploy it. Due to the 2-tier nature of the current architecture this leads to terrible performance (for example, calling a stored procedure that returns 18 result sets). We've used a Citrix solution in the past, but no-one likes that approach. Tunneling JDBC through port 80 also sounds like a bad idea. I was starting to wonder if there's anything that could use a X-Windows like approach to remote just the GUI part.

如果你对这篇内容有疑问,欢迎到本站社区发帖提问 参与讨论,获取更多帮助,或者扫码二维码加入 Web 技术交流群。

扫码二维码加入Web技术交流群

发布评论

需要 登录 才能够评论, 你可以免费 注册 一个本站的账号。

评论(6

仲春光 2024-09-24 11:27:10

要简化开发并充分利用您在 Swing 中的体验,请考虑使用 Vaadin 作为您的前端。它是一个 Java 框架,用于构建外观精美且性能良好的现代 Web 应用程序。所有代码都是用 Java 编写的,看起来与 Swing 非常相似。

就整体应用程序架构而言,我建议采用多层、面向服务的架构。最好的方法是使用Spring 框架和 Hibernate 进行数据库访问

To simplify development and leverage your experience in Swing consider using Vaadin for your frontend. It is a Java framework for building modern web applications that look great, and perform well. All the code is written in Java and looks very similar to Swing.

As far as overall application architecture I would advise multi-tier, service oriented architecture. The best way to do it is by using Spring framework with Hibernate for database access.

最初的梦 2024-09-24 11:27:10

如果您出于更新、安全原因等原因想要轻松地重新部署您的应用程序,并且如果您希望您的应用程序可以远程访问,那么您确实应该考虑基于 Web 的前端。

另外,这样,只有一个应用程序(即您的 Web 应用程序)将处理与数据库的连接,因此不需要 JDBC 隧道或其他任何东西。

关于最好的框架,这取决于您的团队知识、您的应用程序的使用方式(或多或少的 javascript)等。

If you want to easily redeploy your application, for an update, security reasons, etc. and if you want your application to be it to be accessed remotely, you should really consider a web based front end.

Plus, this way, only one app, your web app, will handle connection to the database, so no JDBC tunneling or whatever.

Concerning the best framework, it depends on your team knowledge, the way your application will be used (more or less javascript), etc.

薄荷港 2024-09-24 11:27:10

在迁移遗留应用程序时,我们刚刚经历了非常相似的评估过程。

对于我们来说,使用哪种前端框架的最大决定因素是开发团队的先验知识。我们想要每个人都会立即感到舒服的东西。我们有几位曾与 X 或 Y 合作过的高级开发人员,但每个人都知道的框架是 Swing。

最后,我们决定在 NetBeans 平台上使用 RESTful Web 服务与 EE 服务器进行通信。

作为奖励,您可以将 NetBeans 平台应用程序部署为 Java WebStart 应用程序,这意味着您无需担心单独的安装。

We've just gone through a very similar evaluation process as we're migrating a legacy application.

For us the biggest deciding factor in what front-end framework to use was the prior knowledge of the development team. We wanted something that everybody would be comfortable with immediately. We had a couple of the senior developers that have worked with X or Y, but the framework that everybody knew was Swing.

In the end we decided on the NetBeans platform using RESTful webservice to communicate with an EE server.

As a bonus you can get your NetBeans platform application to deploy as a Java WebStart application, which means you get the benefit of not having to worry about individual installations.

月隐月明月朦胧 2024-09-24 11:27:10

如果前端主要是基于表单的,我会远离 Flex。 Flex 对于某些应用程序来说非常有用(我将它用于基于画布的应用程序),但 Flex 的表单组件存在一些可用性问题。它们只是无法像您期望的当今网络那样工作。 (比如缺少对鼠标滚轮的支持,在下拉列表中输入仅考虑第一个字符等)

If the frontend is mostly form-based, I would stay away from Flex. Flex is great for some applications (I'm using it for a canvas based application), but the form components of Flex has some usability issues. They just don't work like you expect from todays web. (like missing support for mousewheel, typing in dropdownlist only take first character into account etc.)

花落人断肠 2024-09-24 11:27:10

假设您要强制所有客户端安装新的中间层,我想不出反对将其设为 Java Web 应用程序的理由。正如已经提到的,您可以通过 HTTP 控制对平台的所有访问,这样只需配置防火墙即可轻松转售。您没有理由不能在 Web 前端中使用 Javascript,您可能对 DWR< /a>,它允许您通过 Javascript 直接与 Java 对象交互。我之前曾使用过它向 Spring MVC Web 应用程序添加一些简单的 Ajax 交互。

我喜欢这种方法的原因是,您已经将代码迁移到 Java 中间层,因此

  1. 已经对客户端施加了 Java 服务器硬件成本,托管应用程序服务器/Web 服务器具有可比性
  2. 已经具备 Java 专业知识,可以与 DWR 结合使用
  3. 可以尽可能多地使用/little Javascript 适当(我在 IE6、Firefox 3、Chrome 中使用过 DWR)

我认为你对向客户端推送太多功能持谨慎态度是正确的,我会选择尽可能瘦的客户端。我考虑前两个堆栈选择的唯一原因是您是否在特定领域拥有一些开发人员专业知识,而不是 Java webapp/Javascript。

Assuming that you are going to force all your clients to install a new middle tier, I can't think of an argument against making it a Java web app. As already mentioned you have the benefit of controlling all access into your platform over HTTP, which allows easy resale, just with firewall configuration. There's no reason you can't make use of Javascript within a web front end, you may be interested in DWR, which allows you to interact directly with Java objects via Javascript. I've used this before to add some simple Ajax interaction to a Spring MVC webapp.

The reasons I like this approach, you're already migrating code into Java middle tier, so

  1. Already imposing Java server hardware cost on clients, hosting app server / web server is comparable
  2. Already have Java expertise, can be leveraged with DWR
  3. Can use as much/little Javascript as appropriate (I've used DWR with IE6, Firefox 3, Chrome)

I think you're right to be wary of pushing too much functionality to the client, I'd go for as thin a client as possible. The only reason I'd look at the first two stack choices would be if you have some developer expertise in a particular area, and not Java webapp/Javascript.

东走西顾 2024-09-24 11:27:10

我建议创建一个候选框架的简短列表,并使用所有这些框架创建一个小型测试应用程序。通过这种方式,您将了解所有项目的优点和缺点,并了解每个项目的社区活动和文档是什么样的(这些项目有很多差异)。

如果您最终这样做,我希望您将 Vaadin 纳入您的候选名单中,我认为它非常适合您。如果您有任何疑问,请访问我们的论坛,我们将帮助您开始。

I'd suggest to create a short list of candidate frameworks and create a small test application with all of them. This way you will get a sense of good and bad aspects from all of them and also get a picture what the community activity and documentation is like for each project (there is a lot of variance on those).

If you end up doing this I hope you'll include Vaadin in your short list, I think it would fit you very well. If you have any questions just come over to our forums and we'll help you to get started.

~没有更多了~
我们使用 Cookies 和其他技术来定制您的体验包括您的登录状态等。通过阅读我们的 隐私政策 了解更多相关信息。 单击 接受 或继续使用网站,即表示您同意使用 Cookies 和您的相关数据。
原文