Weblogic プロジェクトでは Log4j を使用しましたが、デスクトップ アプリで再度使用したいと考えています。それは悪い考えですか？より良いログ フレームワークを使用する必要がありますか?
いいえ、それは悪い考えではなく、完全に機能します。java.util.logging個人的には、仕事をかなりうまくこなし、アプリケーションのフットプリント（ストレージ）を削減するので、私はそれを使います。ただし、その構成は少しトリッキーです。
Weblogic では、JNDI を使用してデータベース接続を取得しますが、現在は同じことを行うのは不可能のようです。デスクトップ アプリケーションで同じアクションを実行して、リモート データベースに接続するにはどうすればよいですか? c3p0 + データベース ドライバーの組み合わせは、これに適したアプローチですか?
純粋な JDBC API を使用してデータベースに直接接続できますがjava.sql(インターネットで多数の例を入手できます)、独自のデータベース ドライバーをアプリケーション (mySQL、Oracle、DB2 など) の一部として常に配布する必要があります。さらに、独自の API を使用して、これらのドライバーで提供される接続プールを直接使用することができます (かなり簡単にカプセル化できます)。それにもかかわらず、いくつかの問題があります。
- レイテンシ; データベース プロトコルは、レイテンシ (クライアントとデータベース サーバー間の距離) に関してはかなり敏感です。英国にデータベースを持ち、米国にデスクトップ クライアントを持つことは、おそらく良い考えではありません。
- セキュリティ 1; データベース ユーザー資格情報をすべてのデスクトップ クライアントに配布する必要があります。そのことに注意してください。
- セキュリティ 2; データベースのセキュリティ要件によっては、トランスポート セキュリティ (パケット暗号化) が必要になる場合があります。
- 変更管理; 下位互換性のない更新をデータベースに適用するには、すべてのデスクトップ クライアントを更新する必要があります (信じてください。楽しくありません)。
- 通信網; 環境によっては、特定のポートやプロトコルがブロックされる場合があります。
このすべてのもの (ログ + ddbb + メール) を統合ソリューションとして提供するフレームワーク/JAR はありますか? 職場の同僚は、Spring が助けになると言ってくれました。Wareworkも見つけました。
ロギングとデータベース アクセスは問題ではなく、サード パーティのフレームワークがなくても問題なく機能します。もちろん、これらのフレームワークは他の側面 (抽象化、DI、JDBC 抽象化など) に関して価値を提供する可能性がありますが、これは詳細なソフトウェア設計のトピックです。使用しているフレームワークに関係なく、デスクトップ アプリケーションから直接メールを送信すると問題が発生する可能性があります。心に留めておくべきいくつかのこと：
- どの SMTP リレー サーバーを使用しますか?
- 企業環境の場合、IT 運用チームは、各デスクトップから SMTP サーバーを使用することを許可しない場合があります (スパムに注意してください)。
結論:デスクトップのシナリオでは、アプリケーション サーバーも悪い考えではありません。たとえば、JSON、XML、SOAP over HTTP/HTTPS または RMI などを使用してのみ、デスクトップ アプリケーションがアプリケーション サーバーと通信できるようにする必要があります。アプリケーションは、データベース アクセス、トランザクション管理、きめ細かなセキュリティなどの複雑なタスクを担当する必要があります。メールなど