随笔分类 - [04] 架构思想
摘要:《三体》让我们了解了什么是“降维打击”,在软件设计领域很多时候需要反其道而行。对于某个问题,如果不能有效的解决,可以考虑是否可以上升一个维度,从高维视角审视问题往往可以找到捷径。软件设计是抽象的艺术,“升维打击”实际上就是“维度”层面的抽象罢了。
阅读全文
摘要:包含服务注册信息的IServiceCollection对象最终被用来创建作为DI容器的IServiceProvider对象。当需要消费某个服务实例的时候,我们只需要指定服务类型调用IServiceProvider的GetService方法,IServiceProvider就会根据对应的服务注册提供所需的服务实例。
阅读全文
摘要:包含服务注册信息的IServiceCollection对象最终被用来创建作为DI容器的IServiceProvider对象。服务注册就是创建出现相应的ServiceDescriptor对象并将其添加到指定IServiceCollection集合对象中的过程。
阅读全文
摘要:毫不夸张地说,整个ASP.NET Core框架是建立在一个依赖注入框架之上的,它在应用启动时构建请求处理管道过程中,以及利用该管道处理每个请求过程中使用到的服务对象均来源于DI容器。该DI容器不仅为ASP.NET Core框架提供必要的服务,同时作为了应用的服务提供者,依赖注入已经成为了ASP.NET Core应用基本的编程模式。
阅读全文
摘要:名为Cat的DI框架。在《依赖注入[4]: 创建一个简易版的DI框架[上篇]》中我们介绍了Cat的基本编程模式,接下来我们就来聊聊Cat的设计和实现。
阅读全文
摘要:本系列文章旨在剖析.NET Core的依赖注入框架的实现原理,到目前为止我们通过三篇文章(《控制反转》、《基于IoC的设计模式》和《 依赖注入模式》)从纯理论的角度对依赖注入进行了深入论述,为了让读者朋友能够更好地理解.NET Core的依赖注入框架的设计思想和实现原理,我们创建了一个简易版本的DI框架,也就是我们在前面文章中多次提及的Cat。我们会上下两篇来介绍这个被称为为Cat的DI框架。
阅读全文
摘要:IoC主要体现了这样一种设计思想:通过将一组通用流程的控制权从应用转移到框架中以实现对流程的复用,并按照“好莱坞法则”实现应用程序的代码与框架之间的交互。我们可以采用若干设计模式以不同的方式实现IoC,比如我们在《依赖注入[2]: 基于IoC的设计模式》介绍的模板方法、工厂方法和抽象工厂,接下来我们介绍一种更为有价值的IoC模式,即依赖注入(DI:Dependency Injection,以下简称DI)。
阅读全文
摘要:正如我们在《控制反转》提到过的,很多人将IoC理解为一种“面向对象的设计模式”,实际上IoC自身不仅与面向对象没有必然的联系,它也算不上是一种设计模式。一般来讲,设计模式提供了一种解决某种具体问题的方案,但是IoC既没有一个针对性的问题领域,其自身没有提供一种可实施的解决方案,所以我更加倾向于将IoC视为一种设计原则。实际上很多我们熟悉的设计模式背后采用了IoC原则,接下来我们就来介绍几种典型的“设计模式”。
阅读全文
摘要:软件设计中由一些所谓的理念都没有一个明确的定义,比如之前流行的SOA和现在炒的火热的微服务(Micro Service)和无服务器(Serverless),我们都不能通过一个明确的“内涵”给它们一个准确地定义,只能从“外延”上描述这些架构设计应该具有怎样的特性。正因为无法给出一个明确的界定,造成了人们针对同一个概念出现了很多不同的理解。针对IoC也是这种情况,所以本章所诉的仅仅代表作者的一家之言,读者朋友姑妄听之,仅作参考。
阅读全文
摘要:2000年,Roy Thomas Fielding博士在他那篇著名的博士论文《Architectural Styles and the Design of Network-based Software Architectures》中提出了一种软件应用的架构风格。REST是“REpresentational State Transfer”的缩写,可以翻译成“表现状态转换”。
阅读全文
摘要:REST不是一个标准,而是一种软件应用架构风格。基于SOAP的Web服务采用RPC架构,如果说RPC是一种面向操作的架构风格,而REST则是一种面向资源的架构风格。REST是目前业界更为推崇的构建新一代Web服务(或者Web API)的架构风格。由于REST仅仅是一种价格风格,所以它是与具体的技术平台无关的,也就是说采用REST架构的应用未必一定建立在Web之上,所以在正式介绍REST之前,我们先来简单认识一下Web。
阅读全文
摘要:从安全的角度来讲,《中篇》介绍的Implicit类型的Authorization Grant存在这样的两个问题:其一,授权服务器没有对客户端应用进行认证,因为获取Access Token的请求只提供了客户端应用的ClientID而没有提供其ClientSecret;其二,Access Token是授权服务器单独颁发给客户端应用的,照理说对于其他人(包括拥有被访问资源的授权者)应该是不可见的。Authorization Code类型的Authorization Grant很好地解决了这两个问题。
阅读全文
摘要:虽然我们在《上篇》分别讨论了4种预定义的Authorization Grant类型以及它们各自的适用场景的获取Access Token的方式,我想很多之前没有接触过OAuth 2.0的读者朋友们依然会有“不值所云” 之感,所以在介绍的内容中,我们将采用实例演示的方式对Implicit和Authorization Code这两种常用的Authorization Grant作深入介绍。本章着重介绍Implicit Authorization Grant。
阅读全文
摘要:在Internet环境下,我们针对具体的Web应用设计独立的认证系统往往是一件“吃力不讨好”的事情。如果我们开发一个很小的Web应用,可能在实现用户认证功能上面花费的成本比实现应用自身业务功能的成本更大,而且还会因为“信任危机”导致潜在的使用者不敢注册。
在这种情况下,如果一个值得信任的第三方能够提供一种免费的认证服务,那么这两个问题均会迎刃而解。实际上目前这样的第三方认证服务很多,而且他们的提供者均为值得信赖的IT服务提供商,比如微软、Google、Facebook、Twitter,以及国内的新浪、腾讯、网易、人人和豆瓣等。就目前来说,这些第三方认证服务绝大部分均是基于OAuth 2.0设计的。
阅读全文
摘要:本篇文章利用ASP.NET MVC的扩展实现与EntLib的异常处理模块的继承,最终完成了自动化异常处理的实现。通过这个扩展,不仅仅可以采用配置的策略进行异常的处理,还能最终完成各种形式的错误消息的呈现。
阅读全文
摘要:除了通过自定义ControllerFactory的方式引入IoC之外,在使用默认DefaultControllerFactory情况下也可以通过一些扩展使基于IoC的Controller激活成为可能。主要的方式就是自定义ControllerActivator和 DependencyResolver。
阅读全文
摘要:IoC简单地说就是应用本身不负责依赖对象的创建和维护,而交给一个外部容器来负责。这样控制权就由应用转移到了外部IoC容器,控制权就实现了所谓的反转。比如在类型A中需要使用类型B的实例,而B实例的创建并不由A来负责,而是通过外部容器来创建。通过IoC的方式是实现针对目标Controller的激活具有重要的意义。
阅读全文
摘要:作为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。
阅读全文
摘要:在之前一篇介绍CDC的文章中,我说审核跟踪是大部分企业级应用不可以或缺的功能。本篇给你一个完整的解决方案,不仅可以记录每一笔业务操作的信息(比如操作时间、操作者等),并且可以追踪每一笔业务引起的说有数据的改变(如果需要)。
阅读全文