Spring 中的服务门面
Facade of services in Spring
我正在 Spring 开发我的第一个应用程序,但我遇到了设计问题。我已经创建了一些我想通过一些外观使用的服务(这是个好主意吗?)。
我想要这样的结构
/services
/facades
/interfaces
**facades**
/implementations
**sampleFacades**
/interfaces
**services**
/implementations
**sampleServices**
包私有服务(接口和实现)。是否可以,或者我必须将所有 类 放入一个包裹中?
Facade Pattern 旨在创建对更复杂代码的简化和专用访问。
通常,您会有一个由其他人创建的 API,然后您可以创建自己的自定义 API 来使用另一个。
在这种情况下,您似乎是在同一个 Spring 应用程序中为服务创建外观,这对我来说没有意义。
既然可以控制服务定义,为什么还要创建外观?
如果您自己的服务需要一个外观,也许它们没有在正确的粒度级别定义?
请注意,服务的某些复杂性应由其他模式解决,例如 Data Access Objects 由服务协调。
关于将所有 类 放在同一个包中的问题,请考虑 Domain Driven Design 的限界上下文并围绕域而不是实现细节组织代码。
我正在 Spring 开发我的第一个应用程序,但我遇到了设计问题。我已经创建了一些我想通过一些外观使用的服务(这是个好主意吗?)。 我想要这样的结构
/services
/facades
/interfaces
**facades**
/implementations
**sampleFacades**
/interfaces
**services**
/implementations
**sampleServices**
包私有服务(接口和实现)。是否可以,或者我必须将所有 类 放入一个包裹中?
Facade Pattern 旨在创建对更复杂代码的简化和专用访问。
通常,您会有一个由其他人创建的 API,然后您可以创建自己的自定义 API 来使用另一个。
在这种情况下,您似乎是在同一个 Spring 应用程序中为服务创建外观,这对我来说没有意义。
既然可以控制服务定义,为什么还要创建外观?
如果您自己的服务需要一个外观,也许它们没有在正确的粒度级别定义?
请注意,服务的某些复杂性应由其他模式解决,例如 Data Access Objects 由服务协调。
关于将所有 类 放在同一个包中的问题,请考虑 Domain Driven Design 的限界上下文并围绕域而不是实现细节组织代码。