最基础的: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. Oracle性能优化之运行参数设置

    Oracle参数调整建议值 sessions=2150 processes=2000 open_cursors=5120 db_file_multiblock_read_count=64 log_bu ...

  2. Java代码审计sql注入

    java_sec_code 该项目也可以叫做Java Vulnerability Code(Java漏洞代码). 每个漏洞类型代码默认存在安全漏洞(除非本身不存在漏洞),相关修复代码在注释里.具体可查 ...

  3. vs同步配置

    做法(整个流程的过程):1.安装插件2.在GitHub上生成token3.获取gistid4.使用2,3步生成的token和gistid 1.在vscode上安装 settings sync 插件(我 ...

  4. 8.一个项目实战(下载CSDN博客文章)

    专栏地址 ʅ(‾◡◝)ʃ 前言 要写一个下载器,首先要实现一个接口函数,而这个函数可以对请求的数据进行处理也就是爬虫,其次才是写图形化界面 接口的实现 其实CSDN的浏览器页面的接口很复杂,是直接通过 ...

  5. Spring之SpringContext

    一.概述 1.Spring Context概念 创建上下文并将BeanPostProcessor加载到spring 2.Spring Application Context概念 Spring通过应用上 ...

  6. Kafka教程(一)基础入门:基本概念、安装部署、运维监控、命令行使用

    Kafka教程(一)基础入门   1.基本概念   背景   领英->Apache   分布式.消息发布订阅系统   角色   存储系统   消息系统   流处理平台-Kafka Streami ...

  7. 【JUC】循环屏障CyclicBarrier详解

    欢迎关注专栏[JAVA并发] 前言 jdk中提供了许多的并发工具类,大家可能比较熟悉的有CountDownLatch,主要用来阻塞一个线程运行,直到其他线程运行完毕.而jdk还有一个功能类似并发工具类 ...

  8. python中使用pip 安装第三方库报错归类及解决方式

    1.  离线安装virtualenv报错,安装命令:python setup.py install 解决方式:升级setuptools 2.  安装第三方库时安装失败,安装命令:pip install ...

  9. 2021 & 2022年终回顾:山河无恙,烟火寻常

    前言 又到了一年一度年终回顾的时候了,回想起去年年底圣诞节的时候由于忙着参加黑客松大赛,一下子就进入了新的一年,失去了年终回顾的动力,所以今年提前两个月开始进行回顾,这样的话今年最后一天就可以顺利发文 ...

  10. C#开发的线程池和管理器 - 开源研究系列文章

    上次编写了一个小软件,用于练手及自己的一个小工具集合.今天把其中的线程池和管理器的代码抽取出来,写成一个博文,让需要的朋友能够进行学习和应用. 这个线程管理器包括了3个类库和一个应用程序,见下图: 第 ...