什么是构建VB.NET Windows Forms应用程序的最佳方法，使得代码可以被重复利用且应用程序可以轻松扩展？
我曾经创建了很多新窗体。这导致了很多重复的代码和执行类似任务的窗体。
现在，对于执行类似任务的窗体（例如从特定数据库表中查看/编辑/删除项目），我会创建一个具有所需控件的窗体，并使用该窗体创建一个带有参数的类实例，例如包含控件集合和数据库表名称的字符串。然后各个控件调用该类的函数。
高级窗体将继承并扩展此基本窗体类。
我在使用Passive Screen模式方面获得了巨大的成功。
在我看来，传统的MVC架构的一个大问题是人们将太多东西塞进了表单类中。这增加了您需要进行的手动测试量。
您可以在编译后执行越多自动化测试，就能在桌面上发现越多错误。在复杂应用中，即使是微小的更改也往往会产生副作用。
解决此问题的关键是创建一个控制器程序集，该程序集与表单程序集（或EXE）相对应。每个表单都有一个对应的类在程序集中。单击按钮将调用ThisForm.ThisButton(<args>)，然后触发框架中较低级别的对象。每个表单都实现了一个接口，因此，如果控制器类需要从表单中获取其他信息，则具有检索它的接口。
然后，为了进行单元测试，您可以通过实现虚拟类来模拟运算员执行复杂操作，并向控制器类提供事件和信息。由于虚拟类实现了所有预期的接口，因此控制器类不会有任何不同。
有一个重要的例外情况，即对于微不足道的对话框。对于只有几个复选框的对话框，我觉得这个组织方式过度了。我经常使用命令模式。因此，在我定义命令对象的程序集中，我放置与该命令相关联的简单对话框。要获得此处理的对话框必须多简单取决于您。
我喜欢将我的应用程序结构化如下：
Utility - 这是我经常使用的一些东西 - 数学函数、文件函数等的程序集。
Objects - 这包括我正在使用的特定对象。
UIFramework - 这定义了所有表单和控制器接口。
Commands - 这里有所有操作我的应用程序对象的命令对象。
UI - 实现控制器接口的对象
EXE - 实现表单接口并调用控制器对象的表单。
这并不能帮助将UI代码与应用程序逻辑分离，但它使您能够拥有小的、结构化的实体，而不是有着成千上万行代码的表单。
最常针对 CSLA 提出的一个抱怨是它使测试驱动开发变得困难，因此这也是需要考虑的事情。
