随笔分类 - [03] 设计模式
摘要：
包含服务注册信息的IServiceCollection对象最终被用来创建作为DI容器的IServiceProvider对象。当需要消费某个服务实例的时候，我们只需要指定服务类型调用IServiceProvider的GetService方法，IServiceProvider就会根据对应的服务注册提供所需的服务实例。
阅读全文
包含服务注册信息的IServiceCollection对象最终被用来创建作为DI容器的IServiceProvider对象。当需要消费某个服务实例的时候，我们只需要指定服务类型调用IServiceProvider的GetService方法，IServiceProvider就会根据对应的服务注册提供所需的服务实例。
阅读全文
摘要：包含服务注册信息的IServiceCollection对象最终被用来创建作为DI容器的IServiceProvider对象。服务注册就是创建出现相应的ServiceDescriptor对象并将其添加到指定IServiceCollection集合对象中的过程。
阅读全文
包含服务注册信息的IServiceCollection对象最终被用来创建作为DI容器的IServiceProvider对象。服务注册就是创建出现相应的ServiceDescriptor对象并将其添加到指定IServiceCollection集合对象中的过程。
阅读全文
摘要：名为Cat的DI框架。在《依赖注入[4]: 创建一个简易版的DI框架[上篇]》中我们介绍了Cat的基本编程模式，接下来我们就来聊聊Cat的设计和实现。
阅读全文
名为Cat的DI框架。在《依赖注入[4]: 创建一个简易版的DI框架[上篇]》中我们介绍了Cat的基本编程模式，接下来我们就来聊聊Cat的设计和实现。
阅读全文
摘要：本系列文章旨在剖析.NET Core的依赖注入框架的实现原理，到目前为止我们通过三篇文章（《控制反转》、《基于IoC的设计模式》和《 依赖注入模式》）从纯理论的角度对依赖注入进行了深入论述，为了让读者朋友能够更好地理解.NET Core的依赖注入框架的设计思想和实现原理，我们创建了一个简易版本的DI框架，也就是我们在前面文章中多次提及的Cat。我们会上下两篇来介绍这个被称为为Cat的DI框架。
阅读全文
本系列文章旨在剖析.NET Core的依赖注入框架的实现原理，到目前为止我们通过三篇文章（《控制反转》、《基于IoC的设计模式》和《 依赖注入模式》）从纯理论的角度对依赖注入进行了深入论述，为了让读者朋友能够更好地理解.NET Core的依赖注入框架的设计思想和实现原理，我们创建了一个简易版本的DI框架，也就是我们在前面文章中多次提及的Cat。我们会上下两篇来介绍这个被称为为Cat的DI框架。
阅读全文
摘要：IoC主要体现了这样一种设计思想：通过将一组通用流程的控制权从应用转移到框架中以实现对流程的复用，并按照“好莱坞法则”实现应用程序的代码与框架之间的交互。我们可以采用若干设计模式以不同的方式实现IoC，比如我们在《依赖注入[2]: 基于IoC的设计模式》介绍的模板方法、工厂方法和抽象工厂，接下来我们介绍一种更为有价值的IoC模式，即依赖注入（DI：Dependency Injection，以下简称DI）。
阅读全文
IoC主要体现了这样一种设计思想：通过将一组通用流程的控制权从应用转移到框架中以实现对流程的复用，并按照“好莱坞法则”实现应用程序的代码与框架之间的交互。我们可以采用若干设计模式以不同的方式实现IoC，比如我们在《依赖注入[2]: 基于IoC的设计模式》介绍的模板方法、工厂方法和抽象工厂，接下来我们介绍一种更为有价值的IoC模式，即依赖注入（DI：Dependency Injection，以下简称DI）。
阅读全文
摘要：正如我们在《控制反转》提到过的，很多人将IoC理解为一种“面向对象的设计模式”，实际上IoC自身不仅与面向对象没有必然的联系，它也算不上是一种设计模式。一般来讲，设计模式提供了一种解决某种具体问题的方案，但是IoC既没有一个针对性的问题领域，其自身没有提供一种可实施的解决方案，所以我更加倾向于将IoC视为一种设计原则。实际上很多我们熟悉的设计模式背后采用了IoC原则，接下来我们就来介绍几种典型的“设计模式”。
阅读全文
正如我们在《控制反转》提到过的，很多人将IoC理解为一种“面向对象的设计模式”，实际上IoC自身不仅与面向对象没有必然的联系，它也算不上是一种设计模式。一般来讲，设计模式提供了一种解决某种具体问题的方案，但是IoC既没有一个针对性的问题领域，其自身没有提供一种可实施的解决方案，所以我更加倾向于将IoC视为一种设计原则。实际上很多我们熟悉的设计模式背后采用了IoC原则，接下来我们就来介绍几种典型的“设计模式”。
阅读全文
摘要：软件设计中由一些所谓的理念都没有一个明确的定义，比如之前流行的SOA和现在炒的火热的微服务（Micro Service）和无服务器（Serverless），我们都不能通过一个明确的“内涵”给它们一个准确地定义，只能从“外延”上描述这些架构设计应该具有怎样的特性。正因为无法给出一个明确的界定，造成了人们针对同一个概念出现了很多不同的理解。针对IoC也是这种情况，所以本章所诉的仅仅代表作者的一家之言，读者朋友姑妄听之，仅作参考。
阅读全文
软件设计中由一些所谓的理念都没有一个明确的定义，比如之前流行的SOA和现在炒的火热的微服务（Micro Service）和无服务器（Serverless），我们都不能通过一个明确的“内涵”给它们一个准确地定义，只能从“外延”上描述这些架构设计应该具有怎样的特性。正因为无法给出一个明确的界定，造成了人们针对同一个概念出现了很多不同的理解。针对IoC也是这种情况，所以本章所诉的仅仅代表作者的一家之言，读者朋友姑妄听之，仅作参考。
阅读全文
摘要：
IoC主要体现了这样一种设计思想：通过将一组通用流程的控制从应用转移到框架之中以实现对流程的复用，同时采用“好莱坞原则”是应用程序以被动的方式实现对流程的定制。我们可以采用若干设计模式以不同的方式实现IoC，比如我们在上面介绍的模板方法、工厂方法和抽象工厂，接下来我们介绍一种更为有价值的IoC模式，即依赖注入（DI：Dependency Injection，以下简称DI）。
阅读全文
IoC主要体现了这样一种设计思想：通过将一组通用流程的控制从应用转移到框架之中以实现对流程的复用，同时采用“好莱坞原则”是应用程序以被动的方式实现对流程的定制。我们可以采用若干设计模式以不同的方式实现IoC，比如我们在上面介绍的模板方法、工厂方法和抽象工厂，接下来我们介绍一种更为有价值的IoC模式，即依赖注入（DI：Dependency Injection，以下简称DI）。
阅读全文
摘要：相信大家对TransactionScope都比较熟悉。通过TransactionScope，我们可以很容易地将一组操作纳入同一个事务中。我个人觉得这体现了一种可以重用的模式，即本篇文章介绍的Context+ContextScope模式，这种模式旨在一定范围内创建一个可以共享的上下文信息。
阅读全文
相信大家对TransactionScope都比较熟悉。通过TransactionScope，我们可以很容易地将一组操作纳入同一个事务中。我个人觉得这体现了一种可以重用的模式，即本篇文章介绍的Context+ContextScope模式，这种模式旨在一定范围内创建一个可以共享的上下文信息。
阅读全文
摘要：除了通过自定义ControllerFactory的方式引入IoC之外，在使用默认DefaultControllerFactory情况下也可以通过一些扩展使基于IoC的Controller激活成为可能。主要的方式就是自定义ControllerActivator和 DependencyResolver。
阅读全文
除了通过自定义ControllerFactory的方式引入IoC之外，在使用默认DefaultControllerFactory情况下也可以通过一些扩展使基于IoC的Controller激活成为可能。主要的方式就是自定义ControllerActivator和 DependencyResolver。
阅读全文
摘要：IoC简单地说就是应用本身不负责依赖对象的创建和维护，而交给一个外部容器来负责。这样控制权就由应用转移到了外部IoC容器，控制权就实现了所谓的反转。比如在类型A中需要使用类型B的实例，而B实例的创建并不由A来负责，而是通过外部容器来创建。通过IoC的方式是实现针对目标Controller的激活具有重要的意义。
阅读全文
IoC简单地说就是应用本身不负责依赖对象的创建和维护，而交给一个外部容器来负责。这样控制权就由应用转移到了外部IoC容器，控制权就实现了所谓的反转。比如在类型A中需要使用类型B的实例，而B实例的创建并不由A来负责，而是通过外部容器来创建。通过IoC的方式是实现针对目标Controller的激活具有重要的意义。
阅读全文
摘要：
作为MVC最初提出者的Trygve M. H. Reenskau实际是将MVC视为一种范例（Paradigm）,模式和范例的区别在于前者可以直接应用到具体的应用上，而后者则仅仅提供一些基本的指导方针。在软件设计的发展历程中出现了一些MVC的变体（Varation），它们遵循定义在MVC中的基本原理。我们现在来简单地讨论一些一个常用的MVC变体。
阅读全文
作为MVC最初提出者的Trygve M. H. Reenskau实际是将MVC视为一种范例（Paradigm）,模式和范例的区别在于前者可以直接应用到具体的应用上，而后者则仅仅提供一些基本的指导方针。在软件设计的发展历程中出现了一些MVC的变体（Varation），它们遵循定义在MVC中的基本原理。我们现在来简单地讨论一些一个常用的MVC变体。
阅读全文
摘要：MVC是Trygve M. H. Reenskau在1979年访问施乐帕克研究中心（Xerox PARC）期间是提出一种主要针对GUI应用的软件架构模式。MVC体现了关注点分离这一基本的设计方针，它将构成一个人机交互应用涉及到的功能分为Model、Controller和View三部分。本篇文章（上、下篇）为你详细介绍MVC模式和它两个常用的变体MVP和Model2。
阅读全文
MVC是Trygve M. H. Reenskau在1979年访问施乐帕克研究中心（Xerox PARC）期间是提出一种主要针对GUI应用的软件架构模式。MVC体现了关注点分离这一基本的设计方针，它将构成一个人机交互应用涉及到的功能分为Model、Controller和View三部分。本篇文章（上、下篇）为你详细介绍MVC模式和它两个常用的变体MVP和Model2。
阅读全文
摘要：在上篇文章中我们谈到：当我们通过应用DependencyAttribute特性定义需要自动注入的属性的时候，当这个属性为接口、抽象类或者没有定义无参的构造函数，无论我们调用PIAB的Create方法去创建一个新的对象，还是调用Wrap方法对现有对象进行封装，都会抛出异常。如果说在前文中，我们还对这是否是个BUG抱着“谨慎”的态度，那么在这篇文章中，可以肯定地告诉你：这是一个BUG，而且是一个“致命”的BUG。
阅读全文
在上篇文章中我们谈到：当我们通过应用DependencyAttribute特性定义需要自动注入的属性的时候，当这个属性为接口、抽象类或者没有定义无参的构造函数，无论我们调用PIAB的Create方法去创建一个新的对象，还是调用Wrap方法对现有对象进行封装，都会抛出异常。如果说在前文中，我们还对这是否是个BUG抱着“谨慎”的态度，那么在这篇文章中，可以肯定地告诉你：这是一个BUG，而且是一个“致命”的BUG。
阅读全文
摘要：在《这是EnterLib PIAB的BUG吗？》一文中我们讨论了PIAB关于抽象基类的BUG，今天又发现了一个新的问题。问题的起因源于《IoC+AOP的简单实现》这篇文章，因为文中给出的解决方案仅仅支持构造器注入，而不能支持属性注入和方法注入——这是由于EnterLib的PIAB设计本身就存在缺陷。
阅读全文
在《这是EnterLib PIAB的BUG吗？》一文中我们讨论了PIAB关于抽象基类的BUG，今天又发现了一个新的问题。问题的起因源于《IoC+AOP的简单实现》这篇文章，因为文中给出的解决方案仅仅支持构造器注入，而不能支持属性注入和方法注入——这是由于EnterLib的PIAB设计本身就存在缺陷。
阅读全文
摘要：之前园子里也有一些介绍企业库的文章，其中也不乏对Unity的介绍。虽然微软官方声称其为轻量级的IoC框架，但是并不意味着Unity会很简单。相反，也正是因为复杂性，很多人撰文介绍Unity的时候，往往为了面面俱到，导致很多读者不知所云。最终的结果是，了解Unity的读者能够看懂，不懂的人读了还是不懂。在本篇文章中，我试着换一种介绍方式：抓住Unity最本质的东西，剔除一些细枝末节，希望以一种全新的视角让读者了解Unity的本质。
阅读全文
之前园子里也有一些介绍企业库的文章，其中也不乏对Unity的介绍。虽然微软官方声称其为轻量级的IoC框架，但是并不意味着Unity会很简单。相反，也正是因为复杂性，很多人撰文介绍Unity的时候，往往为了面面俱到，导致很多读者不知所云。最终的结果是，了解Unity的读者能够看懂，不懂的人读了还是不懂。在本篇文章中，我试着换一种介绍方式：抓住Unity最本质的东西，剔除一些细枝末节，希望以一种全新的视角让读者了解Unity的本质。
阅读全文
摘要：继EnterLib 4.1之后，微软P&P部门于几天前成功发布了最新版本的EnterLib 5.0。EnterLib 5.0没有增加新的Application Block，主要对现有Application进行了重构和加强，已经对配置的改进。最主要的还是通过IoC让整个EnterLib具有更好的可可扩展性。5.0并将Unity这个IoC容器融入了EnterLib中，并给你创建增加的IoC容器的机会。
阅读全文
继EnterLib 4.1之后，微软P&P部门于几天前成功发布了最新版本的EnterLib 5.0。EnterLib 5.0没有增加新的Application Block，主要对现有Application进行了重构和加强，已经对配置的改进。最主要的还是通过IoC让整个EnterLib具有更好的可可扩展性。5.0并将Unity这个IoC容器融入了EnterLib中，并给你创建增加的IoC容器的机会。
阅读全文
摘要：之前写了一篇名称为《谈谈关于MVP模式中V-P交互问题》的文章，主要表达本人对于MVP模式下V|P关系，以及它们之间的交互应该采用怎样的原则和方式的看法。园子里的朋友对此展开了一些讨论，尤其是是一个叫做非空的朋友转述了另一篇文章提出的关于CAB中关于MVP模式的14条规则，和本人的观点有很多相似之处，当然也有一些不一致的地方。为此，在本篇文章中，就此进行一些必要的补充。
阅读全文
之前写了一篇名称为《谈谈关于MVP模式中V-P交互问题》的文章，主要表达本人对于MVP模式下V|P关系，以及它们之间的交互应该采用怎样的原则和方式的看法。园子里的朋友对此展开了一些讨论，尤其是是一个叫做非空的朋友转述了另一篇文章提出的关于CAB中关于MVP模式的14条规则，和本人的观点有很多相似之处，当然也有一些不一致的地方。为此，在本篇文章中，就此进行一些必要的补充。
阅读全文
摘要：In my current project the MVP pattern is used in the supervising controller mode. The MVP pattern is an adaption of the old MVC pattern that incorporates that the capabilities of WinForms views have become smart enough to lift some of the burdens previously implemented in the controller. This applies to e.g. handling click events and data-binding; a presenter only injects the model into the view which
阅读全文
In my current project the MVP pattern is used in the supervising controller mode. The MVP pattern is an adaption of the old MVC pattern that incorporates that the capabilities of WinForms views have become smart enough to lift some of the burdens previously implemented in the controller. This applies to e.g. handling click events and data-binding; a presenter only injects the model into the view which
阅读全文
摘要：在差不多两年的时间内,我们项目组几十来号人都扑在一个项目上面。这是一个基于SCSF的项目，客户是墨尔本一家事业单位。前两周，我奉命负责对某个模块进行审核工作，在此期间，发现了一些问题，也有了一些想法。不过，有些想法可能还不是很成熟，不能完全保证其正确性，有机会写出来讨论一下。今天来说说关于MVP的一些想法。
阅读全文
在差不多两年的时间内,我们项目组几十来号人都扑在一个项目上面。这是一个基于SCSF的项目，客户是墨尔本一家事业单位。前两周，我奉命负责对某个模块进行审核工作，在此期间，发现了一些问题，也有了一些想法。不过，有些想法可能还不是很成熟，不能完全保证其正确性，有机会写出来讨论一下。今天来说说关于MVP的一些想法。
阅读全文