业务逻辑层和数据访问层:循环依赖

我有一点架构问题.在我的项目中,我有一个业务逻辑层(BLL),其中包含我的所有业务规则,模型和接口的OO API.每个对象都有像getById这样的静态方法,它们返回所述对象的实例.每个对象也有像save和delete这样的方法.这是非常简单的OO代码.

现在我有一个DataAccess层(DAL),包含在一个单独的命名空间中,对于每个BLL对象,我有一个DataClass或"Repository",它执行getById和save命令.所以在某种程度上,BLL save和getById方法是围绕DataClass方法的薄层.

public static NewsItem GetByID(int id)
{
       return DataFactory.GetNewsItemRepository().GetNewsItemById(id);
}

为了让DataClasses返回BLL对象,他们需要知道BLL.所以现在我们有:

GUI ---> BLL <----> DAL

DataFactory只返回实现接口的对象,因此我可以隐藏"OracleNewsItemRepository"之类的实现细节.

但是现在,自从我开始面向对象编程以来一直困扰着我的事情.在我目前的解决方案中,BLL和DAL都需要相互了解.这是循环依赖关系,最佳做法是避免循环依赖关系.另外,我只想公开接口(和我的DataFactory),而不是我的类.这可以通过将DAL层放在单独的Assembly中来完成.这是有道理的.但是,Visual Studio不允许两个程序集相互引用.另一个问题是:C#内部访问修饰符

不知怎的,我认为我的整个数据访问模式错了.感觉就像我正在使用DataMappers等其他东西来卷积ActiveRecord模式.我花了很多时间在Martin Fowler的网站上,但这些模式被描述得非常通用,并用非常抽象的UML图表来说明.

他们没有解决我的问题.也许我有点肛门,而且没有"完美的数据访问模式"这样的东西.我现在所做的事情似乎并不严重.但我现在怎么做,好像......

有任何想法吗？

我认为您的数据访问模式很好.你没有做的是将你的BLL耦合到OracleDAL.您正在耦合到DAL接口.绝对需要一定程度的耦合,否则你永远无法做任何事情.

我假设您的DataFactory和INewsItemRepository类存在于DAL层之外.以下是我的解决方案组织方式的示例.我不使用ActiveRecord,所以这可能不适合你.

Core (Project)
  Domain
    Business Entities
  Data
    Repository Interfaces
    **Your DataFactory**

OracleData (Project)
  Data
    Oracle Repository Implementations

SqlData (Project)
  Data
    Sql Repository Implementations

UI (Project)

希望这可以帮助.

在我看来:

数据访问层(DAL)应使用以下操作在POCO(普通旧CLR对象)上运行:SaveNewsItem ( NewsItemDAO newsItemDAO ).POCO是您的DAO(数据访问对象).

业务层应该包含将数据访问对象(DAO)转换为富业务对象的逻辑,这可能只是DAO加上一些操作以及任何装饰/丰富.

DAL应该完全不了解业务逻辑层.从理论上讲,它应该可以从任何客户端调用.例如,如果您想从应用程序中分离DAL并将其部署为通过WCF公开自己的单独服务,该怎么办？

如上所述,DAL操作,例如SaveNewsItem应该由BO通过接口访问,可能通过依赖注入/ IoC.

您可以使用接口/依赖注入来解决您的问题.

您的业​​务层(BL)包含(可能不止一个)DAL需要实现的数据访问(DA)接口.DAL项目具有对BL的项目引用,以便它们可以吐出业务对象(BO)并实现DA接口.

您的BO可以调用DataFactory,它可以通过依赖注入或反射来实例化DA对象.

我在工作中的许多应用程序(基于Web和智能客户端)中都使用了这种模式,并且它工作得很漂亮.