最基础的: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. mysql删库报错

    3.开发人员测试环境删库报错 #解决:在数据库的物理目录中(mysql的data目录),进入要删除的数据库目录,查看是否有文件存在,若存在,使用rm -rf 命令清除:再次执行删除数据库命令即可 [r ...

  2. CAN总线数据链路层(一)

    1.通信机制 发送报文. 1.首先检测Bus状态,空闲 则发送 报文且回读         2.线与机制,若有两个节点同时发报文          报文结构:          通过ID进行仲裁(规则 ...

  3. Java-ArrayList应用

    存储随机数字 ArrayListRandom.java package cn.day04; import java.util.ArrayList; import java.util.Random; p ...

  4. gRPC(Java) keepAlive机制研究

    基于java gRPC 1.24.2 分析 结论 gRPC keepAlive是grpc框架在应用层面连接保活的一种措施.即当grpc连接上没有业务数据时,是否发送pingpong,以保持连接活跃性, ...

  5. 使用Python实现多线程、多进程、异步IO的socket通信

    多线程实现socket通信服务器端代码 import socket import threading class MyServer(object): def __init__(self): # 初始化 ...

  6. K8s安装乐维5.0应用部署文档

    乐维产品包具体打包为4个镜像包,分别为:mysql5.7.36.tar.zabbix_server.tar.itops_v1_4_x86_64.tar.bpm0.1.tar,对应的配置文件分别为:da ...

  7. 【Day02】Spring Cloud组件的使用--Nacos配置中心、sentinel流量控制、服务网关Gateway、RocketMQ、服务调用链路(Sleuth、zipkin)

    今日内容 一.配置中心 1.遗留问题 yml配置,每一次都需要重启项目 需要不重启项目拿到更新的结果 引出:配置中心 选择:Spring Cloud Config组件 / Alibaba的Nacos( ...

  8. 1.4 Apache Hadoop完全分布式集群搭建-hadoop-最全最完整的保姆级的java大数据学习资料

    目录 1.4 Apache Hadoop 完全分布式集群搭建 1.4.1 虚拟机环境准备 1.4.2 集群规划 1.4.3 安装Hadoop 1.4.3.1 集群配置 1.4.3.1.1 HDFS集群 ...

  9. Django静态文件配置、form表单、request对象、连接数据库、ORM

    目录 静态文件配置 静态文件相关配置 1.接口前缀 浏览器停用缓存 2.接口前缀动态匹配 form表单 action 控制数据提交的地址 method 控制数据提交的方法 请求方法补充 get: 朝服 ...

  10. adb devices出现offline解决方法

    出现offline或者error: more than one device/emulator问题: 解决方法: 输入命令: adb kill-server adb start-server adb ...