假设您正在实现一个用户故事，该用户故事需要在从 UI（或服务外观）到 DB 的所有层中进行更改。
你往哪个方向移动？
- 从 UI 到业务层到存储库到数据库？
- 从数据库到存储库到业务层到 UI？
- 这取决于。（什么 ？）
alex
问问题
796 次
4 回答
2
我见过的此类问题的最佳答案是由 Atomic Object 人员和他们的Presenter First模式提供的。基本上，它是 MVP 模式的一种实现，其中（顾名思义）您从 Presenter 开始工作。
This provides you with a very light-weight object (since the presenter is basically there to marshal data from the Model to the View, and events from the View to the Model) that can directly model your set of user actions. When working on the Presenter, the View and Model are typically defined as interfaces, and mocked, so your initial focus is on defining how the user is interacting with your objects.
I generally like to work in this way, even if I'm not doing a strict MVP pattern. I find that focusing on user interaction helps me create business objects that are easier to interact with. We also use Fitnesse in house for integration testing, and I find that writing the fixtures for Fitnesse while building out my business objects helps keep things focused on the user's perspective of the story.
I have to say, though, that you end up with a pretty interesting TDD cycle when you start with a failing Fitnesse test, then create a failing Unit Test for that functionality, and work your way back up the stack. In some cases I'm also writing Database unit tests, so there is another layer of tests that get to be written, failed, and passed, before the Fitnesse tests pass.
于 2008-09-27T01:52:09.547 回答
1
如果可能发生变化，请从前面开始。您可以立即从股东那里获得反馈。谁知道？也许他们实际上并不知道他们想要什么。观察他们使用界面（UI、服务或其他）。他们的行为可能会激发您以新的眼光看待问题。如果您可以在编码域对象和数据库之前捕获更改，则可以节省大量时间。
如果要求是严格的，那么它就不那么重要了。从可能最困难的层开始——尽早解决风险。归根结底，这是“艺术多于科学”的问题之一。这可能是创建最佳解决方案的层设计之间的微妙相互作用。
干杯。
于 2008-09-25T17:31:52.030 回答
0
我会自下而上，因为你会很快得到一些工作结果（即你可以在没有用户界面的情况下编写单元测试，但在模型完成之前不能测试用户界面）。
不过也有其他意见。
于 2008-09-25T15:45:40.007 回答
0
我将开始对问题域进行建模。创建代表系统实体的相关类。一旦我对此有信心，我就会尝试找到一个可行的映射来将实体持久化到数据库中。如果您在拥有域模型之前在 UI 中投入了太多工作，那么之后您需要重新设计 UI 的风险很大。
考虑到这一点，您可能需要对所有图层进行一些更新...... =）
于 2008-09-25T15:53:40.940 回答