代码之家 › 专栏 › 技术社区 › Matthew Vines

如何将业务层和数据层完全分离?

design-patterns c#

Matthew Vines · 技术社区 · 16 年前

目前,我在应用程序的单个项目中表示我的业务层和数据层。我对这两组类的关注点进行了很好的分离。但是,我的数据层类将作为参数并返回我的业务对象。因此,我将使用类似的代码(请不要对这段代码过于挑剔,我的生产代码看起来不太像这样):

//business class fragment
public bool Save()
{
    if(this.IsValid)
    {
       //DataProvider is one of many data access classes that implement an IDataProvider interface.  Switched elsewhere in the class.  This allows switching of Database providers, xml, etc.
       DataProvider.Save(this);
       return true;
    }
    return false;
}

public List<MyBusinessObject> GetObjectsByCriteria(string criteria)
{
    return DataProvider.GetMyBusinessObjectsByCriteria(criteria);
}

我不希望我的业务类必须处理数据集,就像我喜欢让我的数据层类处理业务类一样。

为了解决这个问题,我读了很多关于数据访问对象或数据传输对象的文章,但对于这些模式来说,这似乎是一个反模式的案例。

我能做什么?如何优雅地实现应用程序这两层的完全分离?

6 回复 | 直到 16 年前

Mark Seemann 16 年前

常见的解决方案是一种称为依赖项注入(DI)的技术。有些人也把它称为控制反转(IoC)。

Inversion of Control Containers and the Dependency Injection pattern

您可以手动实现DI,如 described in this blog post ,或者您可以让DI容器(即框架)为您完成工作。

常见的DI容器有:

duffymo 16 年前

我不认为可以将两者完全分开,但可以确保依赖关系不是双向的。

模型对象(例如,人员、地址、订单等)
服务层(接口,其方法映射到用例、了解工作单元等)
web或视图层(用于web应用的控制器/页面,用于桌面的小部件)。

持久性层、服务层和视图层了解模型对象;模型对象对其所在的层不敏感。

层的依赖关系是单向的,并从前向后流动:

服务->持久性模型
视图->模型、服务

您可以从后面到前面进行单元测试,因为依赖关系使模拟变得容易。

不可能没有依赖项,但是您应该设计它们,这样就没有循环。

唯一一个不依赖项是一个不被任何人调用并且从不调用另一个类的依赖项。这既不是有用的,也不是值得的设计目标。

Bob 16 年前

将持久性逻辑从业务对象中拉出来,并将它们放入数据仓库中 Adapter . 它的工作原理类似于.NET中现有的适配器(OleDbDataAdapter)的工作原理。这样,您还将分离业务对象和持久性逻辑。

您的客户机代码将更加冗长,但我认为这确实是真正分离层的最佳方式。

jlembke 16 年前

执行此操作的流行模式是Repository模式。在本例中,存储库使用集合语义充当门面,完全隐藏持久化数据所在的位置,无论是文件系统还是数据库。您可以实现它来访问数据,然后将数据映射到您想要使用的任何类型。

您可以将域驱动设计作为您正在使用的活动记录模式的替代方案。

Martin K. 16 年前

http://en.wikipedia.org/wiki/Data_Access_Object

http://trac.synyx.org/hades

DAO不是反模式!将它们与Spring和泛型一起使用,您就不必在意;)

每一层之间都有连接!将它们完全分离意味着它们无法进行通信(因此它们是无用的)。

see_sharp_guy 16 年前

n层设计:在业务逻辑层,您可以创建一个数据访问类和一个数据操作类。始终对接口进行编程。