开发N层应用程序。在哪个方向?

我看到的关于这类问题的最佳答案是由原子对象人员和他们的 Presenter First 模式。基本上,它是MVP模式的一个实现,在该模式中(顾名思义),您从演示者开始工作。

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

我通常喜欢这样工作,即使我没有做一个严格的MVP模式。我发现关注用户交互可以帮助我创建更容易交互的业务对象。我们也使用 Fitnesse 在内部进行集成测试,我发现在构建我的业务对象的同时,编写fixtness的夹具有助于将重点放在用户对故事的看法上。

不过,我不得不说,当您开始一个失败的fitness测试,然后为该功能创建一个失败的单元测试,并以您的方式返回堆栈时,您最终会得到一个相当有趣的TDD循环。在某些情况下,我也在编写数据库单元测试,因此在Fitnesse测试通过之前,还有另一层测试需要编写、失败和通过。

如果可能发生变化,从前面开始。你可以立即从股东那里得到反馈。谁知道呢?也许他们实际上不知道自己想要什么。观察他们使用界面(UI、服务或其他)。他们的行动可能会激励你从新的角度看待问题。如果可以在对域对象和数据库进行编码之前捕获更改,则可以节省大量时间。

如果需求是刚性的,那么它就没有那么重要了。从可能是最困难的层开始——尽早解决风险。归根结底,这是一个“比科学更艺术”的问题。这可能是一个微妙的层之间的相互作用,创造了最佳的解决方案。

干杯。

我会自下而上做,因为你会很快得到一些工作结果(也就是说,你可以在没有用户界面的情况下编写单元测试,但是在模型完成之前不能测试用户界面)。

不过,还有其他的看法。

我将开始为问题域建模。创建表示系统实体的相关类。一旦我对此感到自信,我将尝试找到一个可行的映射,用于将实体持久化到数据库中。如果您在拥有域模型之前在UI中投入了太多的工作,那么在之后您需要重新工作UI会有很大的风险。

想想看,你可能无论如何都需要对所有层做一些更新…=)