业务对象和数据层

Question

这个网站为我提供了许多有用的答案，但是经过一个小时的搜索，我找不到任何能够满足我需求的东西。 所以这里......

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

问题是我很难理解这两层之间的交互 ​​- 特别是，如果DAL知道BOL，我已经读过许多文章说过依赖顺序应该是这样的：

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

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

我要在BOL和DAL之间进行中间组装，它基本上是一个薄层，里面装有接口来解耦这两个DLL，因此如果需要，框架可以使用不同的DAL。

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

理想情况下，我们希望使用ORM，因为它只是删除了编写CRUD内容的需要，但我们的客户习惯于在数据库中摆弄列长度，这是我们使用强类型DataTables迄今为止的大多数错误的原因。 。 我听说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){

}

Answer 2

看看SubSonic http://subsonicproject.com/它为大多数数据访问繁琐的工作，它比大多数ORM更容易

Answer 3

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

这是你需要解耦的另一个方向。 所以，只要没有从DAL到BOL的直接耦合，您可以随意更改数据平台。

在这种情况下，为BO创建接口并将它们传递给DAL没什么意义。 但是，您有时可能需要采用其他方式。 通常，业务对象不应该知道有关如何创建或持久化它们的任何信息。

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

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

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

模式并不那么难，只是UI本身是如此混乱，以至于在你觉得你在任何时候编写的代码系统地和有条不紊地努力解耦之前，你可能至少需要几个主要的迭代/应用程序。 UI。 只要继续努力，开始掌握各种技术，并且不要因为你真的没有实现清晰的分离这一事实。 您学到的任何东西都可以做到这一点，甚至可以为在UI上创建一个明确定义的边界做出一点贡献，这是朝着正确方向迈出的重要一步。

Answer 4

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

Answer 5

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

可以以各种方式实现层的分离，最常见的是通过接口和/或MEF或另一个DI / IOC框架。 如果有效地使用，任何这样的技术都实现了足够的解耦。

此外，正如Sisyphus所说，取决于所使用的技术，其中一个分层架构模式将有助于很好地分离关注点：MVC，MVP，MVVM等。我个人推荐使用WPF（桌面）或Silverlight（web）的MVVM但我很高兴有偏见 - 即我喜欢他们两个人去死:)

Answer 6

这是我的发现，
1.使用接口
2.在DAL和BLL之间使用DTO [数据传输对象]
3.将BLL分成两部分，
a. BLL
b. Service Layer
4.使用控制反转（IoC）容器使耦合保持尽可能低。