2

我在工作中继承了一个 vb.net 应用程序，我正在做一些工作。整个应用程序本质上是五千行函数调用。我想在我工作的时候把它清理干净。

我来自网络背景，并且倾向于根据 MVC 范式来考虑应用程序架构。我无法理解思考这个应用程序的正确方法。例如：

  1. 我想将模型层与数据操作和 GUI 逻辑分开。目前正在使用像 DataGridView 这样的 WinForms 组件，据我了解，这让用户基本上可以直接更新数据。我不应该像以前那样拥有一个单独的模型层吗？我的直觉是为每个数据库表创建一个单独的类，让这些类与数据库接口，然后让 GUI 通过实例化/作用于这些类来检索数据。WinForms 组件是否消除了对这种架构的需求？

  2. 我对如何组织设计器的一些自动生成的代码感到困惑。例如，在我的 Web 应用程序中，我将为 UI 的每个部分都有一个 View 对象，该对象将负责渲染和事件处理。在当前代码中，事件处理程序基本上只是单个巨型类中的函数。我应该以同样的方式思考这个问题吗？意思是，当我重构时，我将为 UI 部分提供单独的类，并且我将能够在那里编写事件处理程序？我实际上并不知道所有渲染代码都在哪里。我什至不必担心该代码吗？

任何指针将不胜感激，以及任何可以帮助我理解如何更好地构建代码的资源。

4

3 回答 3

2

您不必担心生成的设计器代码。通常。

我发现设计 WinForms 应用程序的最易理解和可测试的方法是您所指出的 - 类似于您在 Web 编程中所做的。

基本上你有三种（ish）类型的类：

  1. 视图层。这是Windows.Forms.*从这一层继承的任何东西应该是相对愚蠢的。如果您想将显示逻辑放在这一层，这当然是可能的并且是合法的使用，但为了获得最大的可测试性，您可以使用Passive View，其中视图仅引发事件，并且所有属性都由演示者设置

  2. 表示层。这一层决定数据应该如何呈现——哪个视图，如果你使用被动视图模式，那么它还决定颜色、可见性、启用等。这一层可以进行验证等。

  3. 模型层。这是您的业务逻辑所在 - 基本上您的整个业务流程应该能够在模型之间的关系中表示。表示层用于在模型和用户（通过视图）和数据存储（技术上可以被认为是模型）之间进行协调。

还有其他模式，但这是我觉得最自然的一种，并且允许您编写尽可能简单的代码。

于 2013-11-07T20:43:14.763 回答
1

1）拥有一个DAL是个好主意。Entity Framework使用字段作为属性创建表的强类型类。约束和关系仍然存在。

2）您不必弄乱设计器生成的代码文件，因为它们会照顾自己。我认为您不需要为每个UI组件创建一个类——除非我们谈论的是用户控件或子类控件。

于 2013-11-07T20:40:24.037 回答
0

在 #1 上，我从 VB4 天开始就使用模型/视图模式处理 VB 应用程序。不幸的是，很少有经典的 VB 人员这样做，这种趋势延续到 VB.NET。因此，您最终可能会得到大量混合 UI 和数据库调用的杂乱应用程序。你可以重构多少取决于应用程序。在某些情况下，提取模型并构建数据访问层很容易，但在其他情况下，应用程序很容易移动任何东西。

正如 DonA 所提到的，Entity Framework 是一种创建强类型类的简单方法。我发现这种方法的唯一缺点是使用大量预先存在的存储过程。在这种情况下，我使用了我自己设计的简化 DAL 来馈送对象。如果您有直接表和 SP 的混合，您还可以使用 Entity Framework 直接调用 proc 和加载对象。

在 #2 上，在大多数情况下，您不需要更改生成的代码。除非有令人信服的理由手动更改它，否则我会保持原样。一种思考方式是生成的代码是您的视图，而背后的代码是控制器的一种。

您可以做的一件事是让代码更加 DRY 合并验证等，因为您可以轻松地将多个 UI 对象事件分配给单个方法。您经常会在 VB 事件处理中看到重复的代码。整合可以使 VB WinForms 代码更易于管理。

于 2013-11-08T00:31:02.567 回答