0

次の例を考えてみましょう。

3つの層を持つサーバーアプリケーションがあります。クライアントに公開されるサービスレイヤー、永続性に使用されるデータベースレイヤー、および何かを計算するビジネスレイヤー。

このアプリケーションは、3つの異なるタイプのデータを提供します。ユーザー、支払いおよび作業時間。

アプリケーションをどのようにパッケージ化する必要がありますか？レイヤー ごとのパッケージ：

foo.bar.service
  UserService.class
  PaymentsService.class
  WorktimeService.class
foo.bar.persistence
  UserPersistenceService.class
  PaymentPersistenceService.class
  WorktimePersistenceService.class
foo.bar.business
  PaymentCalculator.class

またはタイプ別パッケージ：

foo.bar.user
  UserService.class
  UserPersistenceService.class
foo.bar.payment
  PaymentService.class
  PaymentsPersistenceService.class
  PaymentCalculator.class
foo.bar.worktime
  WorktimeService.class
  WorktimePersistenceService.class

アプリケーションが大きくなり、より多くのロジックが実装されると、最初の例は混乱する可能性があると思います。ただし、タスクが「永続的なサービスレイヤーを拡張して何か凝ったことをする」ことである場合は、適切な場所を見つける方が簡単なようです。2番目の例は、何百万ものクラスでパッケージをフラッディングすることなく、より簡単に拡張できます。

それらから選択するためのベストプラクティスはありますか？それとも、パッケージ構造について他に何か考えがありますか。

4

3 に答える 3

1

私に関する限り、レイヤーとタイプごとにパッケージ化します：

  • foo.bar.service.user.UserService
  • foo.bar.persistence.user.UserPersistence
  • 等々

ほとんどのプロジェクトで、maven といくつかのマルチ モジュールを使用しています。

  1. ドメイン モデル (モデル オブジェクト)
  2. 持続性
  3. サービス
  4. アプリケーション

このようにして、さまざまな jar を取得でき (単純なプロジェクトしかない場合は取得できません)、既存のソースを拡張/変更するのに適した場所を簡単に取得できます。

于 2012-11-09T10:02:43.967 に答える
1

アプリケーションにとってより重要なことは何ですか?

レイヤー/タイプを別のマシンに展開しますか (または将来的に展開する可能性がありますか)?

さまざまな人がさまざまなレイヤー/タイプで作業していますか?

その場合は、レイヤー/タイプを使用してパッケージを分離します。

アプリケーションが少し大きい場合は、おそらく両方を使用することをお勧めします。その結果、次のようなパッケージになります。

foo.bar.<layer>.<type>

また

foo.bar.<type>.<layer>
于 2012-11-09T10:00:59.667 に答える
-1

通常、タイプを入れるモデルパッケージがあります（例では、ユーザー、支払い、および作業時間）。

モデル パッケージの隣には、プレゼンテーションやサービスなどのレイヤー パッケージがあります (通常、サービス パッケージ内にデータ アクセス レイヤーを入れ子にして、これらのレイヤーがサービス実装からのみ使用されるようにしますが、それはあなた次第です)。

プロジェクトが少し大きい場合は、サービス レイヤーを別のモジュールに分割します。それがさらに大きい場合 (またはドメイン モデルが大きくて複雑な場合)、モデル パッケージも別のモジュールに移動し、モデル、サービス、およびプレゼンテーションの 3 つのモジュール プロジェクトを作成します。

複数のプレゼンテーション チャネル (Web アプリケーション、REST サービス、dekstop クライアント アプリなど) もある場合は、これらを個別のモジュールに分割することもできます。

于 2012-11-09T13:21:39.690 に答える