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

Question

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

你朝什么方向移动？

• 从UI到业务层到存储库到数据库？
• 从DB到知识库到业务层到UI？
• 这取决于。 （什么？）

Answer 1

我对这类问题所见到的最好答案是由原子对象家伙提供的和他们的Presenter First模式。基本上它是一个MVP模式的实现，其中（从名字上看）你从Presenter开始工作。

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

我通常喜欢以这种方式工作，即使我没有严格执行MVP模式。我发现专注于用户交互可以帮助我创建易于交互的业务对象。我们还使用Fitnesse进行集成测试，我发现在构建我的业务对象时为Fitnesse编写Fixtures有助于将注意力集中在用户对故事的视角上。我不得不说，当你从一个失败的Fitnesse测试开始，然后为该功能创建一个失败的单元测试，并且按照自己的方式备份堆栈时，最终会出现一个非常有趣的TDD循环。在某些情况下，我还在编写数据库单元测试，因此在Fitnesse测试通过之前，会有另一层测试被写入，失败并通过。

Answer 2

我会自下而上，因为你会有一些工作结果快速（即你可以编写单元测试没有用户界面，但不能测试用户界面，直到模型完成）。

虽然有其他意见。

Answer 3

我会开始建模问题域。创建代表系统实体的相关类。一旦我对此感到有信心，我会尝试找到一个可行的映射来将实体持久化到数据库。如果在创建域模型之前将太多工作投入到用户界面中，那么以后需要重新制作用户界面的风险很大。

想到它，你可能需要做一些更新所有层的反正... =）

Answer 4

如果变化是有可能的，就在前面。你可以得到股东的即时反馈。谁知道？也许他们实际上并不知道他们想要什么。观看他们使用界面（用户界面，服务或其他）。他们的行为可能会激励您以新的视角看待问题。如果在编码域对象和数据库之前可以捕获更改，则可以节省大量时间。

如果要求很严格，那就不那么重要了。从可能最困难的层开始 - 尽早解决风险。最终，这是“更多艺术而不是科学”问题之一。这可能是创建最佳解决方案的层设计之间微妙的相互作用。

干杯。