开发 N 层应用程序。向什么方向发展？

题

假设您正在实现一个用户故事，需要更改从 UI（或服务外观）到数据库的所有层。

你朝什么方向移动？

解决方案

我见过的这类问题的最佳答案是由原子对象人员和他们的主持人优先图案。基本上，它是 MVP 模式的实现，其中（顾名思义）您从 Presenter 开始工作。

这为您提供了一个非常轻量级的对象（因为演示者基本上将数据从模型编组到视图，并将事件从视图编组到模型），可以直接对您的用户操作集进行建模。在使用 Presenter 时，视图和模型通常被定义为接口并进行模拟，因此您最初的重点是定义用户如何与对象交互。

我通常喜欢以这种方式工作，即使我没有采用严格的 MVP 模式。我发现关注用户交互有助于我创建更易于交互的业务对象。我们还使用健身在内部进行集成测试，我发现在构建业务对象时为 Fitnesse 编写固定装置有助于使事情集中在用户的故事角度。

不过，我不得不说，当您从失败的 Fitnesse 测试开始，然后为该功能创建失败的单元测试，并按照自己的方式返回堆栈时，您最终会得到一个非常有趣的 TDD 周期。在某些情况下，我还会编写数据库单元测试，因此在 Fitnesse 测试通过之前还需要编写另一层测试、失败并通过。

其他提示

如果可能发生变化，请从前面开始。您可以立即得到股东的反馈。谁知道？也许他们其实并不知道自己想要什么。观察他们使用界面（UI、服务或其他）。他们的行为可能会激发您以新的眼光看待问题。如果您可以在对域对象和数据库进行编码之前捕获更改，则可以节省大量时间。

如果要求很严格，那么它就不那么重要了。从可能最困难的层面开始 - 尽早解决风险。归根结底，这是“与其说是一门科学，不如说是一门艺术”的问题之一。这可能是层设计之间微妙的相互作用创造了最佳解决方案。

干杯。

我会自下而上地进行，因为你会很快得到一些工作结果（即。e.您可以在没有用户界面的情况下编写单元测试，但在模型完成之前无法测试用户界面）。

不过，还有其他意见。

我将开始对问题域进行建模。创建代表系统实体的相关类。一旦我对此充满信心，我就会尝试找到一个可行的映射来将实体持久保存到数据库。如果您在获得域模型之前在 UI 上投入了太多工作，则存在事后需要重新设计 UI 的重大风险。

想想看，您可能无论如何都需要对所有图层进行一些更新......=)

许可以下： CC-BY-SA 和归因