在我们的 Weblogic 项目中,我们使用了 Log4j,我想在我的桌面应用程序中再次使用它。这是个坏主意吗?我应该使用更好的日志框架吗?
不,这不是一个坏主意,而且效果很好。就个人而言,我会选择它,java.util.logging
因为它可以很好地完成工作,并且它减少了您的应用程序的占用空间(存储)。虽然,它的配置有点棘手。
在 Weblogic 中,我们使用 JNDI 检索数据库连接,但现在似乎不可能这样做。如何在桌面应用程序中执行相同的操作,以便连接远程数据库?c3p0 + 数据库驱动程序的组合是解决这个问题的好方法吗?
您可以使用纯 JDBC API(互联网上提供大量示例)直接连接到数据库java.sql
,但始终必须将专有数据库驱动程序作为应用程序的一部分(mySQL、Oracle、DB2 等)分发。此外,可以通过使用它们的专有 API(相当容易封装)直接使用这些驱动程序提供的连接池。尽管如此,还是有很多问题:
- 潜伏; 数据库协议在延迟(客户端和数据库服务器之间的距离)方面相当敏感。在英国拥有数据库并在美国拥有桌面客户端可能不是一个好主意。
- 安全 1;您必须将数据库用户凭据分发给每个桌面客户端。请注意这一点。
- 安全 2;您的数据库安全要求可能需要传输安全(数据包加密)。
- 更换管理层; 对您的数据库应用非向后兼容更新需要您更新所有桌面客户端(相信我——这并不好玩)。
- 网络; 根据您的环境,某些端口和/或协议可能会被阻止。
是否有任何框架/JAR 提供所有这些东西(日志 + ddbb + 邮件)作为集成解决方案?同事告诉我 Spring 可以提供帮助。我还找到了Warework。
Logging and database access are not an issue and work fairly well without any third-party framework. Of course, those frameworks might provide value regarding other aspects (abstraction, DI, JDBC abstraction, etc.), but this is a topic of detailed software design. Sending emails directly from a desktop application might become an issue, regardless of the framework in use. Just some things to keep in mind:
- which SMTP relay server do you want to use?
- in case of an enterprise environment, your IT operations teams might not allow you to use their SMTP server from each desktop (keep spam in mind).
Conclusion: In desktop scenarios an application server is not a bad idea either. You should have your desktop application to communicate with an application server only by using e.g. JSON, XML, SOAP over HTTP/HTTPS or RMI, etc. The application should be responsible for the complex tasks like database access, transaction management, fine grained security, email, etc.