业务对象和数据层

Question

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

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

问题是我很难理解这两层之间的交互 ​​- 具体来说，如果 DAL 了解 BOL，我读过很多文章，这些文章都说依赖顺序应该是这样的：

GUI / 演示 -->玻尔 ---> DAL

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

我将在 BOL 和 DAL 之间建立一个中间组件，它基本上是一个薄层，其中填充了用于解耦这两个 DLL 的接口，因此如果需要，框架可以使用不同的 DAL。

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

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

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

马龙

Answer 1

这些是我的发现，
1. 使用接口
2.在DAL和DAL之间使用DTO[数据传输对象] BLL
3.将BLL一分为二，
<代码>a. BLL
<代码>b.服务层
4. 使用控制反转 (IoC) 容器来保持尽可能低的耦合。

Answer 2

它还取决于您是否使用/使用什么库/ORM（对象关系映射器）。当使用（好的）ORM 时，DAL 应该是一个非常遥远的问题，因为它几乎完全被 ORM 隐藏；然而，最佳实践表明，即使如此，对于中型到大型应用程序，您也应该在 BOL 和 ORM 之间引入另一层，通常是 DTO（数据传输对象）。 DTO 也可以在没有 ORM 的情况下使用，因为它们只是在单独的库中定义的哑对象，DAL 可以负责持久化它们（将它们转换为数据库结构），而 BOL 可以查询 DAL 并接收这些对象对象。

可以通过多种方式实现层的解耦，最常见的是通过接口和/或 MEF 或其他 DI/IOC 框架。如果有效使用，任何此类技术都可以实现足够的解耦。

另外，根据所使用的技术，正如西西弗斯所说，分层架构模式之一将有助于很好地分离关注点：MVC、MVP、MVVM 等。我个人推荐 MVVM 与 WPF（桌面）或 Silverlight（Web），但我强烈推荐有偏见 - 即我爱死他们了:)

Answer 3

“正确”的方法将根据业务需求而变化。老实说，在很多项目中，我觉得旧式 ado 记录集比现在的许多 ORM 花费的开发时间更少并且更容易维护。花一些时间来确定您的需求是什么，并记住开发时间和可维护性也是应该适当权衡的设计目标。

Answer 4

DAL 需要对 BOL 的引用，以便它可以填充对象。您不希望有任何从 BOL 回到 DAL 的引用或耦合 - 这样做会导致您的 BOL 耦合到特定的数据库实现。当你想到这一点时，这是有道理的。您的 DAL 了解业务对象的详细信息，直至属性级别以及如何从数据库检索其数据 - 当然，DAL 本质上与 BOL 紧密耦合。所以这样的参考就可以了。如果你想一想，另一边是什么？数据库。从对象数据到数据库的“紧密耦合”？是的，它非常紧。这个概念甚至没有多大意义。

这是您需要解耦的所有其他方向。因此，是的，只要没有从 DAL 到 BOL 的直接耦合，您就可以随心所欲地更改数据平台。

在这种情况下，为 BO 创建接口并将其传递给 DAL 没有多大意义。然而，有时您可能需要走另一条路。通常，业务对象不必知道它们是如何创建或持久化的。

例如，在实践中，即使对于大多数 ORM，创建完全没有任何类型的持久性工件的业务层也可能变得非常困难，有时实际上是不可能的。因此，有时您会遇到一些难以解决的问题，并且您可能会发现严格避免在 BO 中拥有任何数据知识会导致您变得过于复杂，这会降低而不是增加价值。

如果您觉得没有更好的方法并且需要从 BOL 中保留某些内容，请创建一个简单的接口，以便可以将 DAL 功能传递到 BOL 中。这样您至少仍然可以保持 BOL 与特定数据库实现分离。

另外，虽然这是很多额外的工作，但除非这是一个非常简单的一次性应用程序，否则我强烈建议您在 UI 和 BOL 之间添加另一层。 MVP（模型-视图-演示者）模式是一种通用设计模式，用于减少核心应用程序和 UI 之间的耦合。 Presenter 有很多变体，不要太关注具体细节，如果您从未使用过，请从简单的 MVP 开始。

这些模式并没有那么难，只是 UI 本身太混乱了，你可能需要至少几次主要的迭代/应用程序才能感觉到你随时编写的代码正在系统地、有条理地解耦用户界面。只要继续努力，开始掌握一系列技术，不要因为你还没有真正实现清晰的分离而纠结。你学到的任何东西以及你能做的任何事情，甚至有助于在 UI 上创建一个明确定义的边界，都是朝着正确方向迈出的一大步。

Answer 5

看看 SubSonic http://subsonicproject.com/ 它为您完成了大部分数据访问繁琐的工作它比大多数 ORM 更容易

Answer 6

我这样做的方式是 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){

}