传统的3层架构与使用IOC的3层架构 [英] Traditional 3 tier architecture vs 3 tier with IOC

查看:119
本文介绍了传统的3层架构与使用IOC的3层架构的处理方法,对大家解决问题具有一定的参考价值,需要的朋友们下面随着小编来一起学习吧!

问题描述

我正在构建一个具有表示层(PL),业务逻辑层(BLL)和数据访问层(DAL)的3层体系结构。
传统的3层体系结构逻辑指出BLL应该充当PL和DAL之间的调解人。 PL甚至不应该知道有数据库,而DAL甚至不应该知道有BLL或PL。

I am building a 3 tier architecture with a Presentation Layer (PL), Business Logic Layer (BLL) and a Data Access Layer (DAL).
Conventional 3 tier architecture logic states that BLL should act as a mediator between the PL and the DAL. The PL shouldn't be even aware that there is a Database while the DAL should not be aware that there is a BLL or a PL.

以上实现将在以下三个不同的物理项目之间产生以下依赖关系

Implementing above would create following dependencies among the 3 different physical projects as follows


  • PL 项目-> BLL DLL的引用

  • BLL 项目-> DAL DLL的引用

  • DAL 项目->无引用



但是,通过在BLL和DAL之间定义IOC的概念,方法是在BLL中定义要DAL实现的接口,并通过构造函数注入使用DI,这将改变依赖关系,如下所示


However applying the concept of IOC between the BLL and the DAL by defining interfaces in the BLL for the DAL to implement and using DI via constructor injection will change the dependency as follows



  • PL    Project-> BLL DLL的引用,DAL DLL的引用(对于构造函数的具体类型的DI BLL对象的数量)

  • BLL  Project->无引用

  • DAL  Project-> BLL DLL的引用(用于实现BLL接口)

IOC和传统的3层冲突?

So are IOC and traditional 3 tier in conflict ?

理想情况下,我想实现以下目标,同时保持自己的IOC与DI一致。

Ideally I want to achieve the following, while maintaining my IOC with DI.



  • PL   项目-> BLL DLL的引用

  • BLL  ;项目->没有引用

  • DAL 项目-> BLL DLL的引用


您如何做?

推荐答案

首先,您可以考虑使用接口解耦您的层,并且可以将接口分离为单独的dll。这样,每一层只依赖于下一层的接口。

First up, you can consider decoupling your layers using interfaces, and the interfaces can be separated into separates dll's. This way, each layer only has a dependency on the interface of the layer below.

我也不知道为什么需要从DAL耦合到BLL?这是回电吗?您可以使用事件代替吗?

I'm also not sure why you would need coupling from DAL to BLL? Is this for call backs? Can't you use events instead?

假设所有3个层都在运行,并且假设您的PL是应用程序(构成根)的入口点,IMO如果使用PL中的引导程序代码分离出接口,通常的依赖关系是:

Assuming all 3 tiers run in process, and assuming your PL is the 'entry point' to your app (Composition Root), IMO the usual dependency if you've separated out interfaces, with the bootstrap code in the PL, is:


  • PL =>引用BLL和DAL(混凝土和接口),以及IoC容器

  • BLL引用DAL(或仅接口,如果适用)

  • DAL无依赖关系(尽管通常会依赖于DTO / POCO /实体)

PL可以将IoC配置卸载到Bootstrapper dll中,从而导致:

The PL can offload the IoC configuration to a Bootstrapper dll, resulting in:


  • PL =>引用BLL接口和引导程序

  • Bootstrapper =>引用所有内容和IoC container

  • BLL =>引用DAL接口

  • DAL =>不依赖(尽管通常会依赖DTO / POCO /实体)
  • PL => References to BLL Interface and bootstrapper
  • Bootstrapper => References everything and the IoC container
  • BLL => References DAL Interface
  • DAL => No Dependency (although usually will have a dependency on DTO / POCO / Entities)

带有某些容器rs,您可以通过使用配置使用配置来避免从引导程序引用所有dll的要求或约定。但是,这些dll显然仍然需要与您的应用程序一起部署。

With some containers, you can avoid the requirement to reference all the dll's from the bootstrapper by using configuration, or convention. However, these dlls obviously still need to be deployed with your app.

这篇关于传统的3层架构与使用IOC的3层架构的文章就介绍到这了,希望我们推荐的答案对大家有所帮助,也希望大家多多支持IT屋!

查看全文
登录 关闭
扫码关注1秒登录
发送“验证码”获取 | 15天全站免登陆