需要有关分层解决方案，关注点分离等方面的建议

Question

我们有一个分层应用程序，或者至少正在转换为一个应用程序，细分如下：

• 接口（用户界面或应用程序界面，即web服务等）
• 业务逻辑
• 数据访问

为了使这个问题的其余部分更加具体，我将描述一个特定的实例。

我们有一个用户界面，后面有一个控制器对象（业务逻辑层）。该控制器通过另一个对象（数据访问层）与数据库通信。

在给定的上下文中，用户界面允许用户选择员工以完成正在进行的操作。由于存在关于用户（以及控制器之外的任何世界）可以选择哪些员工的规则，控制器为此提供了两件事：

• 一个可读属性，包含可供选择的员工列表
• 包含当前所选员工的可读/可写属性

用户界面可能会读取列表并使用它来填充组合框。

在此应用程序的版本1中，组合框包含员工的识别号码+员工的姓名。

一切都很好......

...直到版本1.1，一个错误修正。用户抱怨他无法在 Jimmy Olson 和 Jimmy Olson 之间做出选择，因为该应用程序不足以让他知道哪个是哪个。他知道销售部门有一个Jimmy，开发部门有另一个，所以这个1.1版本的修复就是简单地修改一个斜线+组合框中的部门名称。在版本2中，我们会选择使用具有列支持的组合框替换组合框，删除斜线，但在1.1中，选择此选项是为了最大程度地降低进一步错误的风险。

换句话说，组合框将包含：

• 1 - Jimmy Olson / Sales
• 2 - Jimmy Olson /发展
• • 其他人

但是，用户界面代码没有SQL代码或任何方式来获取该部门，因此我们必须转到控制器并查看那里的代码。控制器不需要部门，说实话，它甚至不需要员工的姓名，识别号码就足够了，所以控制器中没有任何东西要求或对部门做任何事情。所以我们必须转到数据访问层并在那里更改SQL。

这个解决方案非常坦率地说。

如果此控制器有多个接口，具有不同的要求，我们有三种可能的解决方案：

1. 更改数据访问层以满足多个接口（增加/多样化）多个接口（2层之外）的需求，这意味着所有接口都可能获得所需的所有数据，但它们也会获得所有数据任何其他接口所必需的
2. 添加一些让用户界面告诉数据访问层（仍然是2层）所需的内容
3. 以某种方式使用户界面层获取所需数据而不更改所涉及的控制器或访问层，这听起来像是我们需要更多的数据访问代码。

以上解决方案都没有感觉良好。

我想知道的是，我们完全偏离了吗？你会怎么做？是否有第四和第五个解决方案低于上述3？

根据这个问题：Separation of Concerns，接受的答案包含这个引用：

  

关注点的分离是将每个问题的代码分开。更改接口不应该要求更改业务逻辑代码，反之亦然。

这是否意味着所有控制器/数据访问层应该为我们提供它完成工作所需的任何东西（即识别员工数量），然后用户界面应该与数据库通话并询问有关这些特定员工的更多信息？

Answer 1

我看到它的方式，你有两种可能性：

1. 让较低层发送所有 他们有关于的信息 人，可能作为XML文档， 即使很多消费者 这些信息并不需要这一切。
2. 提供更高级别的API 要钻取并获得的图层 他们需要的信息。所以在 你给的情况，有一个方法 界面可以询问业务 要询问数据库层的图层 给予用户ID的部门。

两者都有权衡。第一个可能会向那些对此信息没有任何权利的消费者提供更多信息。第二个每个事务传递的信息少得多，但需要更多事务。每次有更多信息时，第一个都不需要更改API，而是更改XML。第二个保持现有API的接口相同，但随着需求的变化提供新的API。等等。