最基础的:UI-BLL-DAL

这是我们耳熟能详的分层

(补充:)  我们的类正常都不是孤立存在的。很多都是要依赖于其它的类。 比如说我们有一个Work类,Work类在工作的时候需要把信息记录下来。 MessageWriter就是 Worker的依赖项

首先我听到依赖注入之后看似非常的复杂

实际则是:为了实现不同的团队在不同的层上工作。我们可以让一个团队处理数据访问层,一个团队处理业务层,一个团队处理UI。 

首先建立:最基本的三层架构

实体层:

public class Product
{
public Guid Id { get; set; }
public string Name { get; set; }
public string Description { get; set; }
}

数据层:DAL

public class ProductDAL
{
private readonly List<Product> _products; public ProductDAL()
{
_products = new List<Product>
{
new Product { Id = Guid.NewGuid(), Name= "iPhone 9",
Description = "iPhone 9 mobile phone" },
new Product { Id = Guid.NewGuid(), Name= "iPhone X",
Description = "iPhone X mobile phone" }
};
} public IEnumerable<Product> GetProducts()
{
return _products;
} public IEnumerable<Product> GetProducts(string name)
{
return _products
.Where(p => p.Name.Contains(name))
.ToList();
}
}l

逻辑层:BLL

public class ProductBL
{
private readonly ProductDAL _productDAL; public ProductBL()
{
_productDAL = new ProductDAL();
} public IEnumerable<Product> GetProducts()
{
return _productDAL.GetProducts();
} public IEnumerable<Product> GetProducts(string name)
{
return _productDAL.GetProducts(name);
}
}

UI层:UI

class Program
{
static void Main(string[] args)
{
ProductBL productBL = new ProductBL(); var products = productBL.GetProducts(); foreach (var product in products)
{
Console.WriteLine(product.Name);
} Console.ReadKey();
}
}

  以上就是我们基础的结构:  UI - BLL - DAL  引用顺序

那么出现以下三个问题:

1.我们不能让三个不同的团队在每个层上工作。

2.业务层很难扩展,因为它依赖于数据访问层的实现。

3.业务层很难维护,因为它依赖于数据访问层的实现。

高级别对象不应该依赖于低级别对象。两者都必须依赖于抽象。那么抽象概念是什么呢?

抽象是功能的定义。在我们的例子中,业务层依赖于数据访问层来检索图书。在C#中,我们使用接口实现抽象。接口表示功能的抽象。

------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------以下为修改后结构

数据层:DAL 

DAL:接口

public interface IProductDAL
{
IEnumerable<Product> GetProducts();
IEnumerable<Product> GetProducts(string name);
}

DAL:实现 

public class ProductDAL : IProductDAL

业务逻辑层:BLL  这样我们就做到了  使其依赖于IDAL 抽象层,而不是DAL层直接实现:

public class ProductBL
{
private readonly IProductDAL _productDAL; public ProductBL()
{
_productDAL = new ProductDAL();
} public IEnumerable<Product> GetProducts()
{
return _productDAL.GetProducts();
} public IEnumerable<Product> GetProducts(string name)
{
return _productDAL.GetProducts(name);
}
}

 

业务逻辑层:IBLL  (同样的 UI 依赖于BLL 我们也这样做 搞个抽象层 接口)

public interface IProductBL
{
IEnumerable<Product> GetProducts();
IEnumerable<Product> GetProducts(string name);
} 

同理:更新BLL层: 

public class ProductBL : IProductBL

UI层:  就和BLL依赖于DAL一样  UI依赖于BLL

class Program
{
static void Main(string[] args)
{
IProductBL productBL = new ProductBL(); var products = productBL.GetProducts(); foreach (var product in products)
{
Console.WriteLine(product.Name);
} Console.ReadKey();
}

  

----------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------以上为抽象层的建立,

还记得我们标红的地方吗?

public ProductBL()
{
_productDAL = new ProductDAL();
}

BLL依赖于IDAL  ,但是  最终我们还是依赖于DAL

到目前为止,我们所做的工作都与依赖注入无关 

为了使处在BLL依赖于DAL的功能,而没有具体的实现,必须由其他人创建类。其他人必须提供底层对象的具体实现,这就是我们所说的依赖注入。它的字面意思是我们将依赖对象注入到更高级别的对象中。

实现依赖项注入的方法之一是使用构造函数进行依赖项注入。

更新业务层:

public class ProductBL : IProductBL
{
private readonly IProductDAL _productDAL; public ProductBL(IProductDAL productDAL)
{
_productDAL = productDAL;
} public IEnumerable<Product> GetProducts()
{
return _productDAL.GetProducts();
} public IEnumerable<Product> GetProducts(string name)
{
return _productDAL.GetProducts(name);
}
}

  

UI:

class Program
{
static void Main(string[] args)
{
IProductBL productBL = new ProductBL(new ProductDAL()); var products = productBL.GetProducts(); foreach (var product in products)
{
Console.WriteLine(product.Name);
} Console.ReadKey();
}
}

  创建DAL控制与UI结合在一起。这也称为控制反转

我们不是在BLL中创建DAL的实例,而是在UI的中创建它。 Main方法将把实例注入到业务逻辑层。因此,我们将低层对象的实例注入到高层对象的实例中。

                                         这叫做依赖注入

现在,如果我们看一下代码,我们只依赖于业务访问层(BLL)中数据访问层(IDAL)的抽象,而业务访问层(BLL)是使用的是数据访问层实现的接口。因此,我们遵循了更高层次对象和更低层次对象都依赖于抽象的原则,抽象是更高层次对象和更低层次对象之间的契约。

接下来就显示了可维护性和可扩展性的好处。例如,如果我们想为SQL Server创建一个新的数据访问层,我们只需实现数据访问层的抽象并将实例注入基础设施中。

 

原文连接:   www.cnblogs.com/hhhnicvscs/p/14204806.html

原文链接:www.codeproject.com/Articles/5274732/Dependency-Injection-and-IoC-Containers-in-Csharp 

C#依赖注入(直白明了)讲解 一看就会系列的更多相关文章

  1. spring中依赖注入与aop讲解

    一.依赖注入 这个属于IOC依赖注入,也叫控制反转,IOC是说类的实例由容器产生,而不是我们用new的方式创建实例,控制端发生了改变所以叫控制反转. 1 2 3 4 5 6 7 8 9 10 11 1 ...

  2. Angular依赖注入:全面讲解(翻译中)

    在实际使用Angular依赖注入系统时,你需要知道的一切都在本文中.我们将以实用易懂并附带示例的形式解释它的所有高级概念. Angular最强大.最独特的功能之一就是它内置的依赖注入系统. 大多数时候 ...

  3. 看过这些我明白了依赖注入及IoC

    背景 最近一段时间在学习laravel框架,了解到这个框架一个比较核心的概念就是服务容器,而服务容器似乎又和依赖注入有关系.但是碍于官方关于这方面的讲解篇幅过少,所以自学了一下. 自学的途径也跟大家一 ...

  4. [Android]使用Dagger 2依赖注入 - DI介绍(翻译)

    以下内容为原创,欢迎转载,转载请注明 来自天天博客:http://www.cnblogs.com/tiantianbyconan/p/5092083.html 使用Dagger 2依赖注入 - DI介 ...

  5. [ASP.NET MVC 小牛之路]04 - 依赖注入(DI)和Ninject

    本人博客已转移至:http://www.exblr.com/liam  为什么需要依赖注入 在[ASP.NET MVC 小牛之路]系列的理解MVC模式文章中,我们提到MVC的一个重要特征是关注点分离( ...

  6. Android——初探Dagger2依赖注入

    1,在做项目时,经常需要在一个对象里去创建另一个对象的示例,这种行为是产生耦合的常见形式,对于一个大型项目来说,过多的相互依赖会导致代码难以维护,很容易就会碰到修改一个小需求需要大面积的修改各种代码, ...

  7. 依赖注入(DI)和Ninject

    [ASP.NET MVC 小牛之路]04 - 依赖注入(DI)和Ninject 本文目录: 1.为什么需要依赖注入 2.什么是依赖注入 3.使用NuGet安装库 4.使用Ninject的一般步骤 5. ...

  8. Spring 依赖注入优化

    Spring 依赖注入优化 原创: carl.zhao SpringForAll社区 今天 Spring 最大的好处就是依赖注入,关于什么是依赖注入,在Stack Overflow上面有一个问题,如何 ...

  9. React 源码中的依赖注入方法

    一.前言 依赖注入(Dependency Injection)这个概念的兴起已经有很长时间了,把这个概念融入到框架中达到出神入化境地的,非Spring莫属.然而在前端领域,似乎很少会提到这个概念,难道 ...

  10. Spring的核心机制依赖注入

    原文地址:http://developer.51cto.com/art/200610/33311.htm 本文主要讲解依赖注入(设值注入.构造注入),作用是可以使Spring将各层的对象以松耦合的方式 ...

随机推荐

  1. Nginx的概述和配置

    一.Nginx概述 1.1Nginx的特点 (1)一款高性能.轻量级web服务 稳定性高 系统资源消耗低高 对HTTP并发连接的处理能力 (2)单台物理服务器可支持30000~50000个并发请求 1 ...

  2. 【初赛】CSP 2020 第一轮(初赛)模拟记录

    感觉初赛不过关,洛谷上找了一套没做过的来练习. 顺便写了详细的题解. 试题用时:1h 单项选择: 第 1 题 十进制数 114 的相反数的 8 位二进制补码是: A.10001110 B.100011 ...

  3. 状态机的技术选型,yyds!

    前言 今天跟大家分享一个关于"状态机"的话题.状态属性在我们的现实生活中无处不在.比如电商场景会有一系列的订单状态(待支付.待发货.已发货.超时.关闭):员工提交请假申请会有申请状 ...

  4. 嵌入式-C语言基础:指针是存放变量的地址,那为什么要区分类型?

    指针是存放变量的地址,那为什么要区分类型?不能所有类型的变量都用一个类型吗?下面用一个例子来说明这个问题. #include<stdio.h> int main() { int a=0x1 ...

  5. cJson 学习笔记

    cJson 学习笔记 一.前言 思考这么一个问题:对于不同的设备如何进行数据交换?可以考虑使用轻量级别的 JSON 格式. 那么需要我们手写一个 JSON 解析器吗?这大可不必,因为已经有前辈提供了开 ...

  6. 英格索兰扳手网口通信协议EOR原理

    前言 前几天遇到这个需求,需要记录扳手每一次的周期数据,但是我不知道通信协议是什么,只知道是一个tcp的连接,问售后,也不给我网口调试软件(英格索兰自己家的软件).经过我俩天的谷歌,终于找到了他们公司 ...

  7. 重新认识下JVM级别的本地缓存框架Guava Cache(3)——探寻实现细节与核心机制

    大家好,又见面了. 本文是笔者作为掘金技术社区签约作者的身份输出的缓存专栏系列内容,将会通过系列专题,讲清楚缓存的方方面面.如果感兴趣,欢迎关注以获取后续更新. 通过<重新认识下JVM级别的本地 ...

  8. vite安装使用流程

    安装vite 使用npm npm create vite@latest 使用yarn yarn create vite 使用pnpm pnpm create vite 还有一些选择配置比如使用那种框架 ...

  9. 【转载】github.com访问慢解决办法

    打开网站 IPAddress.com ,找到页面中下方的"IP Address Tools – Quick Links" 分别输入github.global.ssl.fastly. ...

  10. 3D视觉算法初学概述

    背景知识 RGB-D相机 一,基于3DMM的三维人脸重建技术概述 1.1,3D 人脸重建概述 1.2,初版 3DMM 二,视觉SLAM算法基础概述 2.1,视觉里程计 2.2,后端优化 2.3,回环检 ...