c# - 业务对象和数据层

Question

该站点为我提供了许多有用的答案，但是经过几个小时的搜索后，我没有找到任何特别满足我需求的内容。所以这里...

我工作的公司正在设计一个新的业务对象层和一个数据访问层——它们将驻留在单独的程序集中。

问题是我很难理解这两层之间的交互——具体来说，如果 DAL 知道 BOL，我读过很多文章，这些文章说依赖顺序应该是这样的这个:

GUI/演示 --> BOL ---> DAL

但据我所知，DAL 需要引用 BOL 才能将对象“返回”到 BOL 层。

我打算在 BOL 和 DAL 之间建立一个中间组件，它基本上是一个薄层，其中填充了用于分离这两个 DLL 的接口(interface)，因此该框架可以在需要时使用不同的 DAL。

这让我想到引入另一个薄层，其中包含 BO 实现的一堆接口(interface)，然后当 BOL 调用 DAL 接口(interface)时，它传递给它一个实现这些 BO 接口(interface)之一的对象，然后 DAL 继续填充对象。这消除了 BOL 和 DAL 之间的所有依赖关系——但是，老实说，我发现很难证明它是合理的。

理想情况下，我们希望使用 ORM，因为它只是消除了编写 CRUD 内容的需要，但我们的客户习惯于摆弄他们数据库中的列长度，这是我们迄今为止使用的大多数错误的原因强类型数据表。我听说 Linq2SQL 也在编译时存储列长度，不确定 NHibernate 是否这样做(但是，我不确定我们的数据库模式是否为 NHibernate 设计得足够干净，处理遗留系统的陷阱)。

是的，任何关于 BOL 和 DAL 之间关系的见解都将非常受欢迎 - 如果上面写得不好，我们深表歉意，如果有人需要澄清，我很乐意提供更多细节。

马龙

Answer 1

我这样做的方式是 BO 期望 DataReader 或 DataContext 或从 DAL 返回的任何内容，而不是实际形成的对象。然后 BO 层的工作是从返回的对象中取出并填充自己。 DAL 不会返回已完成的 BO。要记住的主要事情是，更改 BO 层中的某些内容不应导致 DAL 层出现问题，但更改 DAL 层中的某些内容可能会导致 BO 层出现问题。

我通常做的一个简短例子

在BO层

FillData(){
   DataReader dr = DataLayer.GetData("SomePropertyForAStoreProcedure");
   If dr.Read(){
    Property1 = dr.GetValue("Property1");
    //So on and so forth
   }
}

在 DAL 中

DataReader GetData(String SPProperty){

}