开发方法：用户界面输入或域模型输出？

尽管我从未使用Smalltalk交付过任何东西，但我短暂的使用时间肯定已经留下了印记。描述体验的唯一方法是按原样应有的MVC。本质上，对您的应用程序而言，所有繁重的工作都是在业务对象中完成的（如果您愿意，也可以在域模型中完成）。标准控件以某种方式绑定到业务对象。例如，一个文本框被映射到一个对象的字段（该字段本身是一个对象，因此很容易做到）。一个按钮将映射到一个方法。所有这些都是通过非常简单自然的API完成的。我们不必考虑绑定对象等。它可以正常工作。

但是，在许多更新的语言和API中，您不得不从外部进行思考。首先使用C ++和MFC，现在使用C＃和WPF，Microsoft已将其开发人员吸引到GUI生成器上，在其中可以通过实现事件处理程序来构建应用程序。Java Swing开发并没有什么不同，只有您自己编写代码以实例化表单上的控件。对于某些项目，甚至可能永远都没有域模型-只是事件处理程序。我的大部分职业都在使用该模型。

每种方式都会迫使您以不同的方式思考。使用Smalltalk方法，您的域很聪明，而GUI却很笨。使用默认的VisualStudio方法，您的GUI会很聪明，而域模型（如果存在）则很贫乏。

与我合作的许多开发人员看到了Smalltalk方法的价值，并试图将这种方法引入VisualStudio环境。WPF具有一些动态绑定功能，这使其成为可能。但是有局限性。不可避免地，属于域模型的某些代码最终会出现在GUI类中。

那么，您采用哪种方式设计/开发代码？为什么？

• GUI首先。用户交互至关重要。
• 域优先。在我们将UI放到系统上之前，我需要确保系统是正确的。

两种方法都有优点和缺点。Domain模型适合在那里放置水晶大教堂和空中馅饼。GUI非常适合快速且肮脏的（有时确实很肮脏）。

还有一个额外的好处：如何确保代码可维护？

都没有

多年来，我一直在开发软件，因此发现我自己会实践第一种方法，因为始终需要考虑“中间立场”。在UI代码和业务代码之间放置一个接口，并就当前域中的UI需求达成协议。

让我做出一个数字来使这个概念更加清晰：

  +------+
  |  UI  | <- Think about how to make an effective user interface
  +------+
      |
      |
 +----------+
 | Contract | <--- This part over here is really REALLY important, man!
 +----------+
      |
      |
+--------------+
| Domain model | <- Think about what the user needs
+--------------+ 

这样，如果中间立场明确表明UI可以接收哪些数据，则可以分别在UI和域模型上进行迭代处理。

我之所以看到某些项目变得难以维护，是因为数据和表示之间的接口已经匆忙或不存在（直接数据处理代码位于ui中）。我见过很多项目，其中数据库代码驻留在表单代码中，我对人类失去了信心。我见过的只有少数几个项目有这种僵硬的中间立场，可以恢复失去的信心。

从哪端开始，这实际上并不重要……重要的是，您已经明确地将关注点分离了。中间的合同几乎定义了手头的应用程序或系统。在自下而上或自上而下之前先考虑一下。

域优先。在我们将UI放到系统上之前，我需要确保系统是正确的。

除了简单的情况外，别无他法。

从UI开始，通常会导致易碎，错误的软件，这些软件看起来很有趣，但模型中经常存在严重问题。

并不是先将UI注定要失败-如果模型足够简单，则可以首先构建UI并确信模型最终可以正常工作。

在无法轻易想象模型的任何情况下，都必须先构建模型。

最坏的情况是某些程序员认为他们可以想象模型。他们可能省略了重要的细节，特殊情况，例外或性能方面的考虑。由于已经构建了GUI，并且省略了许多注意事项，因此该模型很糟糕。

这实际上取决于手头的应用程序。

如果要构建封闭的客户端/服务器应用程序，则两种方法都足够；因为您不可避免地要操纵后端以适合前端。

如果要构建一个开放的客户端/服务器应用程序，其中潜在的Web服务将公开给客户使用，那么了解客户如何使用该服务来开发前端就变得至关重要。

关于推动开发中的小迭代周期（Scrum，看板等），通常在最近的某个时候，前端和后端是并行完成的。这是关于提供给定迭代所需的内容；忽略构建它，以防我们需要它的方法。在并行方法中，两端在整个开发过程中保持更近的距离，这可以减轻前端和后端合并时不断变化的需求。如果可行，这是我的首选方法。

你提到...

... WPF具有一些动态绑定功能，使之成为可能；但是有局限性。不可避免地，属于域模型的某些代码最终出现在GUI类中。

不知道你的意思了一些？WPF和SL均以其绑定功能而著称。这是无止境的。如果您被迫在基于MVVM的WPF应用程序中的视图中放置代码，则需要解决一些问题。附加行为是一种无需在View中绑定事件即可实现行为的方法，也是确保View保持干净的许多其他方法。

用户交互立场的前端应该与后端实现无关。后端到前端的唯一工作是通过处理数据或其他方式提供数据。这与正在开发的应用程序类型有关。

实际上，确保源代码可维护是一个完全不同的问题。从高层次上讲，它与最佳编码实践以及以下经过验证的模式，体系结构和技术有关。

我更喜欢先设计基本的UI（即使只是在纸上），也要根据客户的意见进行设计。在看到客户之前，客户可能并不真正知道他们想要什么。您不能总是相信客户告诉您的信息。您可能需要花费数周的时间来编写健壮的域模型，才发现它与客户开始看到UI原型后发现的想法不符。

我们尝试通过自动化测试来驱动我们的软件。自动化的UI测试非常耗时。在控制台上检查某些值的脚本更容易。

考虑到这一点，我们非常小心地将业务逻辑与UI分开。

我记得曾经有一个主要的开发人员对我大吼大叫，当我建议我们需要停止将所有业务代码与UI绑定时（当时我们在C ++中使用Win32，所以这种拖放式编程）被认为是过时的Document / View体系结构甚至不是我们的问题）。我简直傻眼了。

IMNSHO，至少没有业务与UI层是没有任何借口的。如果您的产品做了一些有趣的事情，那么进行这种分离是绝对必要的，以实现代码重用。

作为C＃开发人员，我绝对不认为您会沉迷于由内而外的工作。实际上，我更喜欢先做领域模型。

对于WPF，我所描述的模型的唯一缺点是，有时您需要在UI和域模型之间进行调解。尽管有时这意味着更多的工作，但也意味着代码更简洁。

当然，域名优先！

Smalltalk的优点在于，您可以通过多种方式轻松地“驱动”域模型，包括从工作区或检查器中进行“打印”。只有在确定自己的域能够按预期运行时，才敢于专注于构建完美的GUI。

这并不是说Smalltalkers不能同时处理这两个问题，但是当您的GUI无法实现业务逻辑时，通常会先修复域模型，而不是在GUI中放入特殊情况。