OOP模式设计（数据访问）的常用方法是什么答案

【问题标题】：What's the common way for OOP Pattern design (Data Access)OOP模式设计（数据访问）的常用方法是什么
【发布时间】：2010-09-14 04:27:10
【问题描述】：

最初有一个 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

我最初发现使用共享类时，我不必在需要获取数据时继续创建 DAL 的新实例

Dim _orderDAL as New OrderDal

_orderDAL.GetOrder(1234)

.....

你怎么看？

谢谢

【问题讨论】：

对不起编码。是的，我的应用程序基于订单处理和报告。我所有的数据访问 Insert、Update、Delete、Fetch 都在 DALS 中。从我的前端应用程序（Winforms）中，我通过控制器类访问 DAL，这些类还执行其他一些操作，例如，如果未返回产品，它会将消息发布到特定表单。问题是，控制器类真的有必要吗？最初我将我所有的工作代码（我的命名）捆绑到每个表单上，但是，其他一些表单有重复调用，所以对于 Controller 类和共享函数和 subs，我 w

标签： design-patterns oop multi-tier

【解决方案1】：

我过去曾使用过您的解决方案，但我面临的唯一问题是“共享”或“静态”方法不支持继承。当您的应用程序增长时，您可能非常需要支持不同类型的“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()
    {}
}

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

【讨论】：

【解决方案2】：

这是一个很好的做法——尤其是当您到达控制器需要做的不仅仅是简单地委托给底层 DAL 的时候。

【讨论】：

【解决方案3】：

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

您所做的是一种行之有效的良好做法，将 GUI/表示层与数据层分开。在 GUI 事件方法中包含真实的应用程序代码是一种（可悲的是也很成熟的）不好的做法。

您的控制器类类似于bridge pattern，如果两个层都能够在对方不知道的情况下更改它们的形式，这也是一个好主意。

继续！

【讨论】：

【解决方案4】：

我认为这本优秀的书中列出了几个替代方案：Patterns of Enterprise Application Architecture。您可能感兴趣的一些模式：

【讨论】：

【解决方案5】：

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

问题是，你的数据访问层是什么，有多少？这将决定你做什么。如果你坚持到一个文件，那么我认为你写的很好，如果你需要与系统中的其他控制器共享它，可以将项目包装成一个 singelton（颤抖）。

如果你真的在做订单处理并持久化回数据库，我个人认为是时候看看 ORM 了。这些包将为您处理 CRUM 方面并减少您必须维护的项目数量。

我的 $.02，一旦我看到更好的例子，我保留修改我的答案的权利。

【讨论】：