最初有一个DAL对象，我的BO调用该对象以获取信息，然后将其传递给UI。然后，我开始注意到UI中精简的代码，并且有Controller类。什么是体面的推荐。

我目前正在组织我的

Public Class OrderDAL

    Private _id Integer
    Private _order as Order

    Public Function GetOrder(id as Integer) as Order

        ...return Order

    End Function

End Class

然后我有控制器类(最近实现了这种样式)

Public Class OrderController

    Private Shared _orderDAL as new OrderDAL

    Public Shared Function GetOrder(id) As Order

        Return _orderDAL.GetOrder(id)

    End Function

End Class

然后在我的应用程序中

My app Sub

    Private Sub Button1_Click(ByVal sender As System.Object, ByVal e As System.EventArgs) Handles Button1.Click

        msgbox(OrderController.GetOrder(12345).Customer.Name)

    End Sub

End app

我最初发现，使用Shared Class时，无论何时我需要获取数据时，都不必继续创建DAL的新实例。

Dim _orderDAL as New OrderDal

_orderDAL.GetOrder(1234)

.....

你拿什么

谢谢

解决方案

好了，应用程序不应实例化数据访问层的单独版本，因此我们可以控制它。我们发布的Psuedo代码确实很难阅读。

问题是，数据访问层是多少，多少层？这将决定工作。如果我们对文件感兴趣，那么我认为我们编写的内容很好，并且如果我们需要与系统中的其他控制器共享它，则可以将项目包装到singelton(shudder)中。

如果我们确实在执行订单处理并将其持久化回数据库，那么我个人认为现在是查看ORM的时候了。这些软件包将为我们处理CRUM方面，并减少我们必须维护的项目数量。

我的$ .02，并且我保留在看到更好的示例后修改答案的权利。

我认为这本出色的书中列出了几种替代方法：企业应用程序体系结构的模式。我们可能会感兴趣的一些模式：

• 活动记录
• 表格数据网关
• 行数据网关
• 数据映射器

由于我不是VB开发人员，所以我无法透露VB详细信息，但是：

我们正在做的是一个良好的良好实践，将GUI /表示层与数据层分开。在GUI事件方法中包含实际的应用程序代码是一种(非常糟糕的做法)不好的做法。

控制器类类似于桥接模式，如果两个层都能够在不另一些不知道的情况下更改其形式，这也是一个好主意。

前进！

这是一个好习惯-尤其是当我们到达控制器将需要做的事情不仅仅是简单地委派给基础DAL时。

我过去曾使用过解决方案，而我面临的唯一问题是"共享"或者"静态"方法不支持继承。当应用程序增长时，我们可能非常需要支持不同类型的" OrderControllers"。

理论上，支持不同OrderController的方法是创建工厂：

OrderControllerFactory.ConfiguredOrderController().GetOrder(42);

这里的问题是：" ConfiguredOrderController()"返回什么类型？因为它必须具有静态的" GetOrder(int id)"方法-继承或者接口不支持静态方法。解决此问题的方法是不要在OrderController类中使用静态方法。

public interface IOrderController
{
    Order GetOrder(int Id)
}

public class OrderController: IOrderController
{
    public Order GetOrder(int Id)
    {}
}

和

public class OrderControllerFactory()
{
    public IOrderController ConfiguredOrderController()
    {}
}

因此，通过对控制器使用非静态方法，我们可能会更好。