业务对象和数据层

本网站向我提供了许多有用的答案，但经过一个小时的搜索，我还没有找到任何具体回答我的需求的东西。所以这里...业务对象和数据层

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

问题是我很难让我的头绕着这两层之间的交互 - 具体来说，如果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之间关系的见解都会非常受欢迎 - 如果上述内容写得不好，道歉，如果有人需要澄清，我会很乐意提供更多的细节。

马龙

来源

2010-09-14 Marlon

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

}

来源

2010-09-14 16:43:12 msarchet

一个简单的例子来看看亚音速http://subsonicproject.com/它大部分的数据访问对你来说是单调乏味的工作，它比大多数ORM更容易

来源

2010-09-14 17:07:28 BlackTigerX

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，就从简单的MVP开始。

这些模式并不难，只是UI本身非常混乱，以至于在您觉得您随时编写的代码系统且有条不紊地进行之前，可能需要至少几个主要迭代/应用程序正在努力解耦用户界面。只要继续努力，就可以获得一系列技术，并且不要因为你还没有实现清晰的分离而停下脚步。任何你学习和能够做到的一切，甚至有助于在UI中创建一个明确定义的边界，这是向正确方向迈出的一大步。

来源

2010-09-14 17:08:34 Sisyphus

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

可以通过各种方式实现去耦层，通常通过接口和/或MEF或另一个DI/IOC框架实现。如果有效使用，任何这种技术都可以达到足够的解耦。另外，根据所使用的技术，正如Sisyphus所说，分层架构模式之一将有助于很好地分离关注点：MVC，MVP，MVVM等。我个人推荐MVVM与WPF（桌面）或Silverlight（网络），但我高度偏见 - 即我爱他们两人死亡:)

来源

2010-09-14 17:16:05

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

来源

2012-01-27 00:30:18

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

来源

2012-01-29 14:15:24 Sunil

业务对象和数据层

回答

相关问题