残りの戦争から管理部を分離しましょうか
Struts2を使用してウェブアプリケーションを構築しました。その後、同じ戦争で小さな管理インターフェイスを構築しました。
時が経つにつれ、webappは大きくなり、管理インターフェースも大きくなりました。今、私は別の戦争で管理インターフェースを他のアプリから分離することを考えています
いいアイデアですか？管理戦争とWebアプリケーションの残りの部分を分離することで、パフォーマンス上のメリットはありますか？.
管理部分は主にデータベースの変更/更新/設定を行うことであるため、残りのアプリのUIに直接影響を与えることはありません。それを分離することで、もう一方に影響を与えずに両方の部分を更新できるようになります。
[更新]
ローカルマシンに管理パーツを配置できません。それはウェブアプリです。
Do they use the same classes?いいえ、パッケージ全体が管理アクションでは異なり、ビューも個別です。
How do you update them?戦争をアップロード
Do you use application session?はい、もちろんです。ただし、管理者と通常のユーザーでは異なるセッションが使用されます。
Webアプリケーションのさまざまな部分を別々のwarとして互いに分離することは、アプリケーションサーバーで個々のアプリケーションを停止および再起動でき、各アプリケーションのアクセス制御を単純化できることを意味します。個別のアプリケーションとは、メインアプリケーションがまだ実行されている間に、理論で変更を管理者にデプロイ（オフラインにして、再デプロイ）できることを意味します（理論が強調されていることに注意してください-これについては後で詳しく説明します）。 。
それは本当に利益のためにそれについてです。セッションの数が減ったため、管理ページのパフォーマンスがわずかに向上する場合があります。メインアプリケーションのパフォーマンスが向上することはほとんどありません。
これは、これをはるかに困難にし、いくつかの可能な利益を奪う影響です。
userオブジェクトがあるかどうかを検討してください。これには、管理者またはユーザーが実行できるchangePasswordのようなメソッドがあります。
次の2つのオプションを検討してください。
- hibernateまたは他のormを使用して、ユーザーテーブルにユーザーオブジェクトの注釈を付けている
- データベースに対してネイティブクエリを実行するデータアクセスレイヤーがある
これらについても、2つのオプションがあります。
- ユーザーオブジェクト/データレイヤーの2つのコピー-各戦争に1つ
- 両方のwarsがロードする1つの外部jar
スキーマを変更するたびに（ユーザーまたはデータレイヤーの更新が必要なもの）、少なくとも2倍の作業が必要になります（両方のアプリケーションをリロードしますおよびアプリケーションが同期していることを確認してください）。共有jarを再ロードする必要がありますand両方のアプリケーションを再起動します（アプリケーションサーバーが煩雑な場合は再起動します）。
結局のところ、データオブジェクト（およびデータレイヤー）のセット全体をコピーしたことがわかります。管理者はさらにいくつかを持っているかもしれませんが、メインアプリにあるすべてのものはおそらく管理者にあります。
2つがデータ/モデルを複製する場合、バグの本当の被害者がいます。さらに、ビューが重複していることがわかります（ユーザー更新ページの管理ビューとユーザー更新ページのメインアプリビュー）。
結局のところ、2つのアプリケーションの承認にはわずかな違いしかないことに気付くでしょう-同じ認証、同じデータ、そしておそらく同じビューを共有したいとします。これらは、管理者と通常のユーザーのための異なるコントローラーです。
このことから、すべてを1つのアプリケーションとして保持することをお勧めします。自分を繰り返さないでください。ビューを複製したり、モデルを複製したりしないでください。