最初有一个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)
.....
你有什么看法?
由于
答案 0 :(得分:4)
我认为这本优秀的书中列出了几种替代方案:Patterns of Enterprise Application Architecture。您可能感兴趣的一些模式:
答案 1 :(得分:0)
您的应用程序不应该实例化数据访问层的单独版本,因此您可以控制它。你发布的Psuedo代码真的很难读。
问题是,您的数据访问层是什么,有多少?这将决定你所做的一切。如果您坚持使用文件,那么我认为您所写的内容很好,如果您需要与系统中的其他控制器共享,则可以将项目包装成singelton(不寒而栗)。
如果你真的在进行订单处理并坚持回到数据库,我个人认为是时候看一下ORM了。这些包将为您处理CRUM方面,并减少您必须维护的项目数。
我的$ .02,一旦我看到更好的例子,我保留修改我的答案的权利。
答案 2 :(得分:0)
我不能说VB细节,因为我不是VB开发人员,但是:
您正在做的是一个完善的良好做法,将GUI /表示层与数据层分开。在GUI事件方法中包含真正的应用程序代码是一种(遗憾的是已经确定的)不良做法。
您的控制器类类似于bridge pattern,如果两个层都能够在不知道其他情况的情况下更改其形式,这也是一个好主意。
继续!
答案 3 :(得分:0)
这是一个很好的做法 - 特别是当你到达控制器需要做的事情而不是简单地委托给底层DAL时。
答案 4 :(得分:0)
我过去使用过您的解决方案,我遇到的唯一问题是“共享”或“静态”方法不支持继承。当您的应用程序增长时,您可能需要支持不同类型的“OrderControllers”。
从理论上讲,支持不同OrderControllers的既定方法是创建一个工厂:
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()
{}
}
因此,通过对控制器使用非静态方法可能会更好。