0

考虑以下示例。

有一个具有三层的服务器应用程序。向客户端公开的服务层、用于持久性的数据库层和计算某些东西的业务层。

该应用程序提供三种不同类型的数据。用户、付款和工作时间。

我应该如何打包我的应用程序？逐层 打包：

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

我想如果应用程序增长并且实现越来越多的逻辑，第一个示例可能会变得混乱。但是，当任务是“扩展持久服务层以做一些花哨的事情”时，似乎更容易找到合适的位置。第二个示例可以更容易地扩展，而无需用数百万个类淹没包。

是否有任何最佳实践可供选择？或者你们对包结构有任何其他想法。

4

3 回答 3

1

什么对您的应用程序更重要？

您是否将层/类型部署到不同的机器（或者将来可能想要这样做）？

不同的人在不同的层/类型上工作吗？

如果是这样，请使用层/类型来分隔包。

如果您的应用程序稍微大一点，您可能希望同时使用两者，从而生成类似的包

foo.bar.<layer>.<type>

或者

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

就我而言，我会按层和类型打包：

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

对于我的大多数项目，我使用 maven 和一些多模块：

  1. 领域模型（模型对象）
  2. 持久性
  3. 服务
  4. 应用

通过这种方式，您可以获得不同的 jars（或者如果您只有一个简单的项目，则不会），并且更容易检索扩展/修改现有源的好地方。

于 2012-11-09T10:02:43.967 回答
-1

通常有一个模型包，您可以在其中放置类型（在您的示例中为用户、付款和工作时间）。

在模型包旁边有层包，如表示和服务（我通常在服务包中嵌套数据访问层，以鼓励这些层仅在服务实现中使用，但这取决于您）。

如果项目有点大，我将服务层拆分为一个单独的模块。如果它仍然更大（或者域模型又大又复杂），我也会将模型包移动到一个单独的模块中，从而产生一个三模块项目：模型、服务和演示。

如果还有多个演示通道（例如 Web 应用程序、REST 服务和 dekstop 客户端应用程序），这些也可以拆分为单独的模块。

于 2012-11-09T13:21:39.690 回答