我正在实现一个数据访问层(DAL),它基本上是一组具有(VB.NET)实现执行数据库(CRUD)调用的共享函数的类。我试图找出在类层次结构中调用DAL的最佳位置。让我举个例子。
假设我有一个Customer类,只有标准ID,Name,Address1等属性,可能还有一个重写的ToString函数。我还有一个带有共享方法的DAL类,例如:
(pseudocode)
Namespace Dal
Public Class Customer
Public Shared Function Read(id As Integer) As Customer
Public Shared Function ReadList() As List(Of Customer)
Public Shared Sub Create(c As Customer)
'etc.
现在,我可以像这样从表示层调用Dal:
Me.DataGridView1.Datasource = Dal.Customer.ReadList
然而,让表达层完全了解Dal是不是一个好习惯?我应该把方法放在Customer对象中并像这样调用Dal吗?
Public Function ReadList() As List(Of Customer)
Return Dal.Customer.ReadList()
End Sub
Public Sub Create()
Dal.Customer.Create(Me)
End Sub
这会是“更清洁”的OOP吗?或者,让演示文稿调用Dal,传递业务对象,如我之前的示例:
,这是否可以接受Me.DataGridView1.Datasource = Dal.Customer.ReadList
Dim c As New Customer
c.Name = "Alpha Corporation"
c.Address1 = "123 Main Street"
Dal.Customer.Create(c)
感谢您的反馈。
答案 0 :(得分:4)
您的应用程序对DAL的了解越少越好。有几种方法可以做到这一点,我认为你走在正确的轨道上。我想您可能希望查看此实现的factory pattern,因为您将能够隐藏工厂后面的DAL实现并从工厂返回实体和实体集合。
答案 1 :(得分:2)
我同意数据调用不属于UI层。这些仅供演示。
我认为它们恰好属于服务层。服务实现使用模型对象和持久层来实现其目标。无论是基于XML的Web服务还是本地接口,该服务都是映射到用例并了解工作单元的对象。
将数据库调用放入单独的持久层,或者将它们嵌入到模型对象中,以获得额外的面向对象的纯度。
答案 2 :(得分:1)
您希望将CRUD操作拉入单独的层的原因是您想要更改数据库系统。好吧,这就是我做到的原因。我不建议这样做只是为了好OOD。但是,你走了......
几组类/接口
BusinessObject - 表示业务类型实体(如Customer),将DataManager作为属性。
DataManager - 也许你可以想出一个更好的名字,但是这个东西为BusinessObjects提供了Load()和Save()函数
SearchList - 返回事物列表,您的SQL查询在这里。此应该表现得像一个带有Next(),Eof()和CurrentRecord类型成员的RecordSet
构造函数/工厂 - 请参阅FactoryPattern。您已经从业务对象中解除了数据库操作的耦合,这个事物以必要的方式重新耦合它们。为BusinessObject
分配适当的数据管理器实现想出你想要的任何实际名字,但让我们再谈谈客户。假设您有一个Oracle数据库。你可能最终得到这些类:
继承自BusinessObject的boCustomer
继承或实现DataManager的oracleDMCustomer
searchlistCustomer,它继承自通过抽象方法或类似接口公开的搜索列表:
oracleSearchlistCustomer - 实现searchlistCustomer,实际上会实现SearchAll()和SearchByZip()
boFactory - 一个静态类,其方法类似于CreateObject(类型类型)
searchlistFactory - 一个静态类,其方法看起来像CreateSearchList(Type type);
我会让你填写一些空白,但我认为重要的东西就在那里。其他人可能有不同的想法,需要较少的抽象。在与一个策略合作之前,我会模拟几个策略。