在web项目中，我们可以在不了解UI的情况下编写核心服务层吗？

Question

我正在开展网络项目。我们使用flex作为UI层。我的问题通常是我们分别从Web / UI层编写核心服务层，因此我们可以为不同的UI层/技术重用相同的服务。因此，实际上可以重用相同的核心层服务而无需在API中使用不同类型的UI技术/层进行任何更改/添加。对于例如与UI技术相同的核心服务层，支持同步请求响应（例如jsp等）和非同步或事件驱动的UI技术（例如Ajax，Flex，GWT等）或多种设备（如计算机，移动设备，pdas等） 。就个人而言，我觉得在没有任何UI知识的情况下编写核心服务层非常困难。寻找其他人的想法。

Answer 1

当然可以。服务层通常是无状态的，因此它只提供了使用来自UI的参数调用的方法。您可以将其想象为从UI层调用的API。重要的是不将任何与UI相关的内容作为参数传递。例如，不要将HttpServletRequest或HttpSession作为参数传递 - 获取所需的值并传递它们。

Answer 2

在没有UI知识的情况下编写核心服务并不困难。

核心服务只需知道执行任务所需的数据（来自哪里无关紧要）。

一旦你设计了核心服务，你就可以在它们之上构建几个不同的用户界面，收集必要的数据并将其传递给服务......然后执行他们的特定职责。

Answer 3

  

我的问题往往是我们写的   核心服务层分开   web / UI层，所以我们可以重用相同的   针对不同UI的服务   层/技术

服务层应该与UI无关，所以实际上非常好。

  

例如相同的核心服务层   支持UI技术   同步请求响应（例如   jsp等）和非同步或事件   驱动的UI技术（例如Ajax，Flex，   GWT等）或多个设备   喜欢（电脑，手机，pdas等）。

在服务层中公开的业务操作理论上应该不依赖于谁调用它以及使用哪种技术。但是你似乎面临着常见的症状：

1. 不同的用户界面确实需要略有不同的业务运营（例如，移动和非移动来电者返回的数据量可能不同）
2. 业务运营与远程技术相结合（例如，同步与异步）

对于1.问题，您必须问自己，您是否可以优雅地考虑这些略有不同的操作，或者相反，如何优雅地暴露相同操作的变体。在这两种情况下，应该可以设计一致且满足各种客户需求的服务API。

对于2.你必须问自己的问题是如何将业务运营与远程技术分离。可以引入桥接器或适配器或额外的中介层，但这不应导致过度工程化。

我知道有时很难将业务运营与实际使用完全分开。让我们考虑分页：如果业务操作是“我想要查询X的数据”，那么暴露的具体操作也会嵌入一些UI的知识，即分页。

我只能提供一般建议：在数据，格式等方面争取在UI和业务之间进行明确分离，当你不能的时候，尝试找出对所有人都有意义的最通用的API客户端。

  

我个人觉得很难   写任何没有的核心服务层   UI知识。

我同意这有点困难，但你似乎做得对 - 所以继续这样：）