.NET架构与模式

最新推荐文章于 2023-06-08 23:28:32 发布
最新推荐文章于 2023-06-08 23:28:32 发布
阅读量2.2k 收藏
点赞数
分类专栏： 基础知识 文章标签： .net application 设计模式 架构设计 microsoft 分布式应用
版权声明：本文为博主原创文章，遵循 CC 4.0 BY-SA 版权协议，转载请附上原文出处链接和本声明。
本文链接：https://blog.csdn.net/wuyanhuiyishi/article/details/398288
版权

.NET架构与模式

作者：微软架构与模式小组

什么是架构

    软件体系结构通常被称为架构，指可以预制和可重构的软件框架结构。架构尚处在发展期，对于其定义，学术界尚未形成一个统一的意见，而不同角度的视点也会造成软件体系结构的不同理解，以下是一些主流的标准观点。

    ANSI/IEEE 610.12-1990软件工程标准词汇对于体系结构定义是：“体系架构是以构件、构件之间的关系、构件与环境之间的关系为内容的某一系统的基本组织结构以及知道上述内容设计与演化的原理(principle)”。

    Mary Shaw和David Garlan认为软件体系结构是软件设计过程中，超越计算中的算法设计和数据结构设计的一个层次。体系结构问题包括各个方面的组织和全局控制结构，通信协议、同步，数据存储，给设计元素分配特定功能，设计元素的组织，规模和性能，在各设计方案之间进行选择。Garlan & Shaw模型[1]的基本思想是：软件体系结构={构件(component),连接件(connector)，约束(constrain)}．其中构件可以是一组代码，如程序的模块；也可以是一个独立的程序，如数据库服务器。连接件可以是过程调用、管道、远程过程调用(RPC)等，用于表示构件之间的相互作用。约束一般为对象连接时的规则，或指明构件连接的形式和条件，例如，上层构件可要求下层构件的服务，反之不行；两对象不得递规地发送消息；代码复制迁移的一致性约束；什么条件下此种连接无效等。

    关于架构的定义还有很多其他观点，比如Bass定义、Booch & Rumbaugh &Jacobson定义、Perry & Wolf模型[7]、Boehm模型等等，虽然各种定义关键架构的角度不同，研究对象也略有侧重，但其核心的内容都是软件系统的结构，其中以Garlan & Shaw模型为代表，强调了体系结构的基本要素是构件、连接件及其约束（或者连接语义），这些定义大部分是从构造的角度来甚至软件体系结构，而IEEE的定义不仅强调了系统的基本组成，同时强调了体系结构的环境即和外界的交互。

什么是模式

    模式（Pattern）的概念最早由建筑大师Christopher Alexander于二十世纪七十年代提出，应用于建筑领域，八十年代中期由Ward Cunningham和Kent Beck将其思想引入到软件领域，Christopher Alexander将模式分为三个部分：首先是周境（Context，也可以称着上下文）,指模式在何种状况下发生作用；其二是动机（System of Forces）,意指问题或预期的目标；其三是解决方案（Solution）,指平衡各动机或解决所阐述问题的一个构造或配置（Configuration）。他提出，模式是表示周境、动机、解决方案三个方面关系的一个规则，每个模式描述了一个在某种周境下不断重复发生的问题，以及该问题解决方案的核心所在，模式即是一个事物（thing）又是一个过程(process)，不仅描述该事物本身，而且提出了通过怎样的过程来产生该事物。这一定义已被软件界广为接受。

    软件模式的应用对软件开发产生了重大的作用，主要表现在：

  • 软件模式是人们在长期的设计软件、管理组织软件开发等实践中大量经验的提炼和抽象，是复用软件设计方法、过程管理经验的有力工具。模式类似于拳击中的组合拳，它提供了一系列软件开发中的思维套路。如，通过模式的使用，有利于在复杂的系统中产生简洁、精巧的设计。
  • 软件模式为我们提供了一套简洁通用的设计、管理、组织方面的词汇，同时模式也为我们提供了一个描述抽象事物的规范标准，可大大促进软件开发过程中人与人之间的交流，而软件开发中的交流是至关重要的，“软件项目失败的原因最终都可追溯到信息没有及时准确地传递到应该接收它的人”。

架构和模式的关系

    因为架构(Architecture)和模式(Pattern)在当前的软件开发中经常地被提及，可是很多人容易混淆这两个术语，而对此，学术界也没有一个非常统一的定义。

    架构和模式应该是一个属于相互涵盖的过程，但是总体来说Architecture更加关注的是所谓的High-Level Design,而模式关注的重点在于通过经验提取的“准则或指导方案”在设计中的应用，因此在不同层面考虑问题的时候就形成了不同问题域上的Pattern。模式的目标是，把共通问题中的不变部分和变化部分分离出来。不变的部分，就构成了模式，因此，模式是一个经验提取的“准则”，并且在一次一次的实践中得到验证，在不同的层次有不同的模式，小到语言实现(如Singleton)大到架构。在不同的层面上，模式提供不同层面的指导。根据处理问题的粒度不同，从高到低，模式分为3个层次：架构模式(Architectural Pattern)、设计模式(Design Pattern)、实现模式(Implementation Pattern).架构模式是模式中的最高层次，描述软件系统里的基本的结构组织或纲要，通常提供一组事先定义好的子系统，指定它们的责任，并给出把它们组织在一起的法则和指南。比如，用户和文件系统安全策略模型，N-层结构，组件对象服务等，我们熟知的MVC结构也属于架构模式的层次。一个架构模式常常可以分解成很多个设计模式的联合使用。设计模式是模式中的第二层次，用来处理程序设计中反复出现的问题。例如，[GOF95][2]总结的23个基本设计模式——Factory Pattern, Observer Pattern等等。实现模式是最低也是最具体的层次，处理具体到编程语言的问题。比如，类名，变量名，函数名的命名规则；异常处理的规则等等。

    相对于系统分析或者设计模式来说，体系结构从更高的层面去考虑问题，所以关注的问题就体现在“不变”因素上，比如系统部署中，更加关心应用程序的分层分级设计，而在这个基础之上提出的部署方案，才是架构考虑的重点。体系结构关心应用程序模式，更加体现在通过技术去解决这些业务差异带来的影响，关心是否是分布式应用程序，关心系统分层是如何设计，也关心性能和安全，因此在这样的情况之下，会考虑集群，负载平衡，故障迁移等等一系列技术。

    希望通过定义的方式来区分架构和模式是不太可能的，因为本来就是交互交叉和提供服务的，它实际上是架构模式，而不是设计模式。在大部份情况下，表现为下面几个设计模式之一：Strategy模式、Mediator模式、Composite模式、Observer模式。对于熟悉架构设计的系统架构师而言，似乎可以用如下来解释架构和模式之间的关系：架构是Hight-Level Design,着眼于不同业务中共性的解决方案，而模式是General Principle(通用原理)。

企业解决方案的构建模式

    企业级业务解决方案是公司实现其业务的赌注，它们通常极其复杂，而且性能必须不负众望。它们不仅必须具有高可用性和伸缩性以应对不可预知的使用，而且还必须具有适应性和预见性以适应快速变化的业务要求。最佳解决方案是那些由一组更小的、简单的、能够可靠且有效地解决简单问题的机制组成的解决方案。在构建更大、更复杂的系统过程中，将这些简单的机制组合在一起，从而形成更大的系统。对这些简单机制的认识来之不易。它通常存在于有经验的开发人员和体系结构设计者的头脑中，并且是他们潜意识中自然带到项目中的重要知识。

    模式对于开发人员和体系结构设计者非常有用，因为它们：

  • 记录能够正常工作的简单机制。
  • 为开发人员和体系结构设计者提供通用的词汇和分类法。
  • 允许以模式组合的方式简明扼要地描述方案。
  • 允许重复使用体系结构、设计和实现决策。

模式可以记录简单机制

    模式描述给定上下文中反复出现的问题，并基于一组指导性影响因素来建议解决方案。解决方案通常是一种简单的机制，是为了解决模式中所标示出的问题而一起工作的两个或多个类、对象、服务、进程、线程、组件或节点之间的协作。

    您正在构建一个报价应用程序，其中有一个类负责管理系统中的所有报价。很重要的一点是，所有报价都应与该类的一个（而且只与一个）实例进行交互。如何构造您的设计，以便从该应用程序中只能访问该类的一个实例？

    解决该问题最简单的方案就是创建一个具有私用构造函数的QuoteManager类，以便任何其他类都不能实例化它。此类包含QuoteManager的一个静态实例，并使用名为GetInstance()的静态方法返回。此代码大体如下所示：

public class QuoteManager
{
    //注意：仅适用于单线程应用程序
    private static QuoteManager _Instance = null;

    private QuoteManager() {}

    public static QuoteManager GetInstance()
    {
        if (_Instance==null)
        {
            _Instance = new QuoteManager ();
        }
        return _Instance;
    }

    //... QuoteManager提供的函数
}

    您可能已经像其他许多开发人员那样通过类似的方式解决过类似的问题。实际上，注意反复出现的问题并寻求解决方案的模式作者已经屡次发现了这种实现，提取出了通用解决方案并将这种问题-解决方案对称为Singleton模式[GOF95]。

问题-解决方案对模式


图1 简化的Singleton模式

    通过将图1中简化的模式示例与QuoteManager源代码进行比较，阐明了模式（通用问题-解决方案对）和模式应用程序（针对非常具体的问题的具体解决方案）之间的区别。模式级别的解决方案是多个类之间简单但极其顺畅的协作。模式中的通用协作专门适用于QuoteManager类，提供了用来控制报价应用程序中实例化的机制。显然，您可以稍微修改一下某种模式以满足局部的特定要求，所以同一种模式可以应用于无数个应用程序。

    所编写的模式提供了一种记录简单且经过证实的机制的有效方法。模式是以特定格式编写的，这一点对于装载复杂思想的容器非常有用。这些模式在被记载和起名之前，就早已存在于开发人员的大脑及其代码中。

位于不同级别的模式

    模式存在于多个不同的抽象级别中。考虑另一个示例（这次所处的抽象级别比源代码要高一级）：

    您要设计一个基于Web的报价应用程序，其中包含大量业务和表示逻辑，这些逻辑反过来依赖大量平台软件组件来提供适当的执行环境。如何在高级别组织系统以使其在具有灵活、松耦合性的同时仍具有高内聚性？

    此问题的解决方案之一涉及到按一系列层来组织系统，每层包含大致位于同一抽象级别的元素。随后，确定每一层中的依赖性，并确定采用严格还是宽松的分层策略。接着，决定是打算创建自定义的分层方案，还是采用以前由其他人记录的分层方案。在本例中，假设您决定使用众所周知的分层策略：表示、业务逻辑和数据访问各占一层。图2显示了分层方案的可能外观。


图2 报价应用程序的层

    如果您总是按这种方式设计系统，说明您已经在不依赖于任何广义模式的情况下使用该模式。即便如此，您还可能因多种原因而希望了解支撑这种设计方法的模式。您可能迫切想知道为何经常以这种方式构建系统，或者可能在寻找更理想的方法来解决此模式不能完全解决的问题。使用层作为高级别组织方法是Layers（层）模式[Buschmann96][3]中描述的完善模式。图3显示了该模式的简化版本。


图3 简化的Layers模式

    这个简单的应用程序组织策略有助于解决软件开发中面临的两个挑战：依存关系的管理和对可交换组件的需求。如果在构建应用程序时没有一个考虑周全的依存关系管理策略，会导致组件易损坏且不牢靠，从而导致对它们进行维护、扩展和替代时存在较大的困难，而且成本较高。

    Layers模式中的工作机制比Singleton中的工作机制更精细。对于Layers，首次协作是在设计时发生在类之间，这是由于分层组织将对更改源代码所带来的影响局部化，从而防止所做的更改贯穿到整个系统。第二次协作发生在运行时：某层中相对独立的组件变得可与其他组件交换，再一次使系统其余部分不受影响。

    尽管Layers模式的通用性足以应用于诸如网络协议、平台软件和虚拟机之类的领域，但是它无法解决企业类业务解决方案中存在的某些特定问题。例如，除通过分解来管理复杂性（由Layers解决的基本问题）外，业务解决方案开发人员还需要进行适当组织，以便有效地重复使用业务逻辑并保留与昂贵资源（如数据库）的重要连接。解决此问题的方法之一就是使用Three-Layered Application（三层应用程序）模式。图4显示了该模式的简化说明。


图4 简化的Three-Layered Application

    同样，在模式(Three-Layered Application)和模式应用程序（报价应用程序分层模型）之间存在区别。模式是有关应用程序组织主题的通用问题-解决方案对，而模式应用程序是通过创建具体的层来解决非常具体的问题。

模式的优化

    Three-Layered Application实际上是在Layers的基础上进行的简单优化；在Layers中确定的上下文、影响因素和解决方案仍适用于Three-Layered Application，但反之不行。也就是说，Layers模式约束着Three-Layered Application模式，而Three-Layered Application模式优化了Layers模式。

    您为某个发展迅速的成功企业构建了一个报价应用程序。现在，您希望通过向业务合作伙伴公开自己的报价引擎并将其他合作伙伴服务（如配送）集成到该报价应用程序中来扩展该应用程序。您将如何构造自己的业务应用程序以提供和享受服务？

    此问题的解决方案之一是通过将其他与服务相关的职责添加到每一层中来扩展Three-Layered Application。在业务层添加了以下职责：通过Service Interfaces（服务接口）向客户应用程序提供一组简化的操作。数据访问层的职责拓宽到了数据库和主机集成之外，以包括与其他服务提供者的通信。将数据访问层中的这个附加功能封装到服务接口组件中，这些组件负责连接到服务（同步和异步）、管理服务的基本会话状态并向业务流程组件通知与服务相关的重大事件。

    Three-Layered Services Application（三层服务应用程序）（图5）记录了该问题-解决方案对。


图5 简化的Three-Layered Services Application

    将Three-Layered Services Application模式应用于报价应用程序示例将形成如下模型。


图6 应用于报价应用程序的Three-Layered Services Application

    请注意这些模式之间的关系（请参阅图7）。Layers引进了一个用来组织软件应用程序的基本策略。Three-Layered Application优化了此概念，并将它限制在需要重复使用业务逻辑、灵活部署和高效使用连接的业务系统的范围内。Three-Layered Services Application又在Three-Layered Application的基础上进行了优化，并对设计进行了扩展，以便在提供和使用其来源千差万别的数据和逻辑时，将这些数据和逻辑处理为粒状元素。


图7 相关模式的优

    向特定层中添加其他类型的组件并不是管理这种日益增长的复杂性的唯一方法。正如复杂性所证实的那样，设计人员通常在应用程序中创建其他层来承担该职责。例如，一些设计人员将服务接口移到一个单独的层中。而另外一些设计人员将业务层分隔成域层和应用程序层。在任何情况下，您有时可能会看到某些设计人员在使用此模式来满足复杂要求时，有时会将这三层扩展到四层、五层或者甚至六层。与之相反，Layers模式也用在相对简单的客户端-服务器应用程序中。

    解决方案简述：术语“解决方案”有两种截然不同的含义：其一是表示模式本身的一部分（如某上下文中包含的问题-解决方案对）；其二是表示业务解决方案。在使用“业务解决方案”这一术语时，它是指专用来满足一组特定的功能和操作业务要求的软件密集型系统。软件密集型系统意味着您不只是关心软件，而且还必须将该软件部署到硬件处理节点以提供整体的技术解决方案。而且，所考虑的软件不仅包括自定义开发的软件，而且包括购买的软件基础结构和平台组件，所有这些都被集成在了一起。

结束语

    以.NET为代表的Microsoft产品线向我们展示了“架构为基础，模式为指导”的企业解决方案设计理念，秉承微软产品一贯以来的简单易用以外，同时我们将看到使用.NET构建企业应用平台上使用.NET的优势。毫不夸张地说，.NET不是第一个体现架构和模式的软件应用平台，确是目前为止最后的实现了架构和模式的平台，在随后的文章介绍中，你将会发现，架构设计和模式应用会是如此简单。

[1] 《软件体系结构（影印版）》，科学出版社2004年1月1日出版。Mary Shaw、David Garlan合著，原文书名《Software Architecture: Perspectives on an Emerging Discipline》。

[2] GoF95，《设计模式——可复用面向对象软件的基础》，Erich Gamma、Richard Helm等著，英文版本《Design Patterns: Elements of Reusable Object-Oriented Software》，这是设计模式领域的经典之作，它结合设计实例从面向对象的设计中精选出23个设计模式，总结了面向对象设计中最有价值的经验，并且用简洁可复用的形式表达出来。

[3] [Buschmann96] Buschmann，Frank，《Pattern-Oriented Software Architecture》，John Wiley & Sons Ltd，1996。中文版《面向模式的软件体系结构》，2003年1月机械工业出版社出版。

posted on 2004年12月30日 3:09 PM

href="http://editblog.csdn.net/msdncolumn/Services/Pingback.aspx" rel="pingback"/> #  online poker 2005-05-26 4:35 PM online poker

You can also check out some relevant pages about online poker http://www.williamchibbard.com/online-poker.html
texas hold em http://www.texas-hold-em-world.com/texas-hold-em.html
online poker http://www.texas-hold-em-world.com/online-poker.html
texas hold em http://www.e-online-poker-777.com/texas-hold-em.html
online poker http://www.e-online-poker-777.com/online-poker.html
...

# online poker 2005-05-26 4:36 PM online poker

You can also check out some relevant pages about online poker http://www.williamchibbard.com/online-poker.html
texas hold em http://www.texas-hold-em-world.com/texas-hold-em.html
online poker http://www.texas-hold-em-world.com/online-poker.html
texas hold em http://www.e-online-poker-777.com/texas-hold-em.html
online poker http://www.e-online-poker-777.com/online-poker.html
...

wuyanhuiyishi
关注
  • 0
    点赞
  • 踩
  • 0
    收藏
    觉得还不错? 一键收藏
  • 0
    评论
专栏目录
C#学习记录——.NET的三层架构
做有价值的事，积累有价值的笔记！
10-26 2453
典型的三层结构包括表示层、业务逻辑层和数据访问层。使用三层结构创建的应用系统，由于层与层之间的低耦合、层内部的高内聚，使得解决方案的维护和增强变得更容易。通常所说的三层结构包括表示层、业务逻辑层、数据访问层。采用分层设计的软件可维护行、可重用性、可延展性都比较好。三层结构示意图如下图：□ 表示层：主要是指与用户交互的界面，用于显示数据和接收用户输入的数据。将用户输入的数据传递给业务逻辑层，一般不包含任何实际的业务处理，当业务逻辑层的数据发生变化时，表示层就会显示出更新的结果。
.NET平台框架解读
最新发布
分享DotNet技术和日常开发笔记，DotNet，Python为主。
06-30 4587
Net人员解决了代码共享问题，但是仅用于开发类库，意思就是说如果你的类库是.Net Standard规范的，那么此类库既可以是.Net Framework也可以是.Net Core类库。直到.NET Core，.NET才算真正的跨平台，这也是微软重大的战略转变。.NET Core是一种模块化实现，可用于各种垂直领域，从数据中心扩展到基于触摸的设备，它是开源的，跨平台的，能在Windows、Linux、MacOS等操作系统上运行，同时还支持Docker等容器化环境安装和部署。
.net 软件开发模式——三层架构
2203_75593971的博客
06-08 6178
需要注意的是，不同的数据访问技术和开发框架通常有不同的 SqlHelper 实现方式，例如在 ASP.NET 中，我们通常使用 SqlHelper 类来访问 SQL Server 数据库，而在 Entity Framework 中，我们可以使用 DbContext 来管理数据访问逻辑，或者使用 LINQ 表达式来查询数据。1.查询操作返回的是DataTable 是一个 C# 中的数据表格类，它代表了一个内存中的数据表格，提供了一种方便的方法来存储和操作数据。下面分别介绍在 .NET 中如何实现这三层架构。
NET框架程序设计-第1章.NET框架开发平台体系架构
用来学习的地方
05-29 1841
（比如所定义的类型和它们的成员），另外还有一些用于描述托管模块中。
.NET框架结构体系及工作原理
柳落青
01-10 4367
1：.NET框架运行在操作系统之上，是.NET最基础的框架。 它提供了创建，部署和运行.NET应用的环境，主要包含公共语言运行时(CLR)和框架类库(.NET Framwork 类库,FCL)，并且支持多种开发语言。.NET框架可以安装在Windows操作系统上，支持C#,C++,VB,.NET等开发语言，也就是我们所说的跨语言开发。 2：.NET框架具有两个主要组件：CLR和FCL。 CLR是.......
.NET架构师比较全面的学习资料
04-12
4. **架构模式**：掌握如MVC（Model-View-Controller）、MVVM（Model-View-ViewModel）、微服务等架构模式，理解它们在不同场景下的应用。 5. **ASP.NET**：深入学习ASP.NET Web Forms、ASP.NET MVC、ASP.NET Core ...
.NET通用开发架构
05-18
.NET通用开发架构是一种高效、可复用且可扩展的软件开发模式，主要基于Microsoft的.NET Framework或.NET Core（现在统称为.NET）。这种架构为开发者提供了标准化的开发流程，旨在提高软件项目的质量和生产效率，减少...
分层架构模式.NET架构和模式.pdf
10-02
分层架构模式.NET架构和模式.pdf
.NET几种微服务框架，你用过吗？
zls365365的博客
05-11 698
最近有群友问，.NET有哪些微服务框架？.NET的微服务框架还真不多，一般企业都会自己搭建微服务框架，或者基于其它框架搭建微服务（比如abp）。本文将介绍几种微服务框架，供大家学习参考。Service Fabric简介：Service Fabric 是一个微服务框架，它由微软开发并托管在 Azure 上。它提供了一种分布式系统的方式，允许开发人员在云、本地和边缘环境中构建高可用性、可扩展的...
完整的基于泛形、SOA设计思想的.net 框架　Demo 代码
12-11
完整的基于泛形、SOA设计思想的.net 框架从ORM、Meta（Entity）、BO、SO、Exchange、SDO、服务层代理层、CS客户端主要的代码为工具生成
.net分布式开发框架
04-26
.net分布式开发框架
.Net分层架构设计
09-05
.NET开发过程中常用的分层思想及实践，包含了Attribute在实际开发中使用的例子
Spring.net框架
06-11
你真的了解Ioc与AOP吗？ 收藏 你真的了解Ioc与AOP吗？我现在还不是很了解，而且越学习越发现自己了解的很少，Ioc与AOP中蕴涵了大量的能量等待我们去开发。在这个系列 中，我仅仅利用Sping.net这个框架向大家展示一下Ioc与AOP的强大功能（呵呵，其实写这段话的目的是因为“文章题目”牛皮吹得有点大了，给自 己个台阶下罢了）。 在这个系列中一共包含6个案例，从简单到复杂，也是对问题分解、思考和解决的一个过程，它们分别是： （1）类之间的依赖； 降低 （2）接口依赖； （3）基 于配置文件和Reflection的工厂模式； （4）使用Spring.net实现Ioc； （5）Romoting； （6）利用Ioc在不动一行代码的情 况下实现Remoting。为了更好的理解文中的内容，最好顺序阅读。 作为一个应用系统，代码复用至关重要。如果在你的设计中，类与类存在很强的相互关联，那么你会发现在重用这些组件时就存在很严重的问题。在 Step1到Step3-Reflection的例子中，我们试图 利用“针对接口编程”以及自己设计的Ioc对系统进行解耦。在Step3到Step5的例子中，我们将利用Spring.net提供的Ioc框架，轻松完 成解耦以及系统改造等工作。 一、类之间的依赖 我们的第一个例子主要用于说明程序的基本构造，并且作为一个反面典型，引出为什么要解耦，以及如何下手。在这个例子中，我们将创建三个程序集，分别是MainApp.exe、HelloGenerator.dll以及SayHello.dll。它们之间的关系如下图所示： HelloGenerator类根据提供的姓名产生一个问候字符串，代码如下： using System; namespace IocInCSharp { public class EnHelloGenerator { public string GetHelloString(string name) { return String.Format("Hello, {0}", name); } } } SayHello类持有一个对EnHelloGenerator的引用，并负责将生成出来的问候字符串打印出来。 using System; namespace IocInCSharp { public class SayHello { private EnHelloGenerator _helloGen; public EnHelloGenerator HelloGenerator { get { return _helloGen; } set { _helloGen = value; } } public void SayHelloTo(string name) { if(_helloGen != null) Console.WriteLine(_helloGen.GetHelloString(name)); else Console.WriteLine("Client.hello is not initialized"); } } } MainApp.exe负责完成对象的创建、组装以及调用工作： using System; namespace IocInCSharp { public class MainApp { public static void Main() { SayHello sayHello = new SayHello(); sayHello.HelloGenerator = new EnHelloGenerator(); sayHello.SayHelloTo("zhenyulu"); } } } 在这个设计中，组件与组件之间、类与类之间存在着紧密的耦合关系。SayHello类中的_helloGen字段类型为 EnHelloGenerator，这将导致我们很难给它赋予一个其它的HelloGenerator（例如CnHelloGenerator，用于生成 中文问候语）。另外MainApp也严重依赖于SayHello.dll以及HelloGenerator.dll，在程序中我们可以看到类似new SayHello();new EnHelloGenerator();的命令。 这种紧密的耦合关系导致组件的复用性降低。试想，如果想复用SayHello组件，那么我们不得不连同HelloGenerator一同拷贝过去， 因为SayHello.dll是依赖与HelloGenerator.dll的。解决这个问题的办法就是“针对抽象（接口）”编程 （依赖倒置原则）。这里的抽象既包括抽象类也包括接口。我不想过多的去谈抽象类和接口的区别，在后续的例子中我们将使用接口。由于接口在进行“动态代理” 时仍能保持类型信息，而抽象类可能由于代理的原因导致继承关系的“截断”（如MixIn等）。除此之外，对于单继承的C#语言而言，使用接口可以拥有更大 的弹性。 二、接口依赖 既然类之间的依赖导致耦合过于紧密，按照《设计模式》的理论，我们要依赖于接口。但是人们往往发现，仅仅依赖于接口似乎并不能完全解决问题。我们从上面的例子中抽象出接口后，组件间的依赖关系可能变成如下图所示： 经过改造后，SayHello不再依赖于具体的HelloGenerator，而是依赖于IHelloGenerator接口，如此一来，我们可以 动态的将EnHelloGenerator或是CnHelloGenerator赋给SayHello，其打印行为也随之发生改变。接口的定义以及改造后 的SayHello代码如下（为了节省空间，将代码合并书写）： using System; namespace IocInCSharp { public interface IHelloGenerator { string GetHelloString(string name); } public interface ISayHello { IHelloGenerator HelloGenerator{ get; set; } void SayHelloTo(string name); } public class SayHello : ISayHello { private IHelloGenerator _helloGen; public IHelloGenerator HelloGenerator { get { return _helloGen; } set { _helloGen = value; } } public void SayHelloTo(string name) { if(_helloGen != null) Console.WriteLine(_helloGen.GetHelloString(name)); else Console.WriteLine("Client.hello is not initialized"); } } } 但是我们的MainApp似乎并没有从接口抽象中得到什么好处，从图中看，MainApp居然依赖于三个组件：ICommon.dll、 HelloGenerator.dll以及SayHello.dll。这是由于MainApp在这里负责整体的“装配”工作。如果这三个组件中的任何一个 发生变化，都将导致MainApp.exe的重新编译和部署。从这个角度来看，似乎“针对接口编程”并没有为我们带来太多的好处。 如果能够将“组件装配”工作抽象出来，我们就可以将MainApp的复杂依赖关系加以简化，从而 进一步实现解耦。为此，我们引入“工厂”模式，并利用配置文件和反射技术，动态加载和装配相关组件。 三、基于配置文件和Reflection的工厂模式 为了消除MainApp对其它组件的依赖性，我们引入工厂模式，并且根据配置文件指定的装配规程，利用.net提供的反射技术完成对象的组装工作。 本部分代码仅仅提供一种功能演示，如果实际应用仍需进一步完善（建议使用一些成型的Ioc框架，例如Spring.net或Castle等）。经过改造后 的系统，组件间依赖关系如下图： 可以看出这次实现了真正的“针对接口编程”。所有的组件只依赖于接口。MainApp所需的对象是由工厂根据配置文件动态创建并组装起来的。当系统 需求发生变化时，只需要修改一下配置文件就可以了。而且MainApp、SayHello和HelloGenerator之间不存在任何的依赖关系，实现 了松耦合。 这是如何实现的呢？我们首先要能够解析配置文件中的信息，然后建立包含相关信息的对象。最后根据这些信息利用反射机制完成对象的创建。首先我们看一下配置文件所包含的内容： 从中我们可以看出，我们实现了一个IocInCSharp.ConfigHandler类，用来处理配置文件中IocInCSharp\ objects结点中的内容。ConfigHandler类将根据该结点下的内容处理并创建一ConfigInfo对象（关于ConfigInfo、 ObjectInfo以及PropertyInfo的代码可自行查看源代码，这里就不再赘述）。ConfigHandler类的代码实现如下： using System; using System.Configuration; using System.Xml; namespace IocInCSharp { public class ConfigHandler:IConfigurationSectionHandler { public object Create(object parent, object configContext, System.Xml.XmlNode section) { ObjectInfo info; PropertyInfo propInfo; ConfigInfo cfgInfo = new ConfigInfo(); foreach(XmlNode node in section.ChildNodes) { info = new ObjectInfo(); info.name = node.Attributes["name"].Value; info.assemblyName = node.Attributes["assembly"].Value; info.typeName = node.Attributes["typeName"].Value; foreach(XmlNode prop in node) { propInfo = new PropertyInfo(); propInfo.propertyName = prop.Attributes["name"].Value; propInfo.assemblyName = prop.Attributes["assembly"].Value; propInfo.typeName = prop.Attributes["typeName"].Value; info.properties.Add(propInfo); } cfgInfo.Objects.Add(info); } return cfgInfo; } } } 通过ConfigHandler的解析，我们最终得到一个ConfigInfo实例，Factory就是根据这个实例中所包含的配置信息，利用反射技术对所需对象生成并组装的。SayHelloFactory的代码如下： using System; using System.IO; using System.Configuration; using System.Reflection; namespace IocInCSharp { public class SayHelloFactory { public static object Create(string name) { Assembly assembly; object o = null; object p; string rootPath = Path.GetDirectoryName(Assembly.GetEntryAssembly().Location) + Path.DirectorySeparatorChar; ConfigInfo cfgInfo = (ConfigInfo)ConfigurationSettings.GetConfig("IocInCSharp/objects"); ObjectInfo info = cfgInfo.FindByName(name); if(info != null) { assembly = Assembly.LoadFile(rootPath + info.assemblyName); o = assembly.CreateInstance(info.typeName); Type t = o.GetType(); for(int i=0; i<info.properties.Count; i++) { PropertyInfo prop = (PropertyInfo)info.properties[i]; assembly = Assembly.LoadFile(rootPath + prop.assemblyName); p = assembly.CreateInstance(prop.typeName); t.InvokeMember(prop.propertyName, BindingFlags.DeclaredOnly | BindingFlags.Public | BindingFlags.NonPublic | BindingFlags.Instance | BindingFlags.SetProperty, null, o, new Object[] {p}); } } return o; } } } 在上面这段代码中，重点注意三条命令的使用方法： assembly = Assembly.LoadFile(rootPath + prop.assemblyName); p = assembly.CreateInstance(prop.typeName); t.InvokeMember(prop.propertyName, BindingFlags.DeclaredOnly | BindingFlags.Public | BindingFlags.NonPublic | BindingFlags.Instance | BindingFlags.SetProperty, null, o, new Object[] {p}); Assembly.LoadFile()用于将外部文件装载进来；assembly.CreateInstance()根据装载进来的程序集创建一指定类型的对象；t.InvokeMember(prop.propertyName, ........BindingFlags.SetProperty, null, o, new Object[] {p})利用反射机制对创建出来的对象设置属性值。 我们的Factory就是利用这种方式根据配置文件动态加载程序集，动态创建对象并设置属性的。有了这个Factory，MainApp中的内容就很简单了： using System; namespace IocInCSharp { public class MainApp { public static void Main() { ISayHello sayHello = (ISayHello)SayHelloFactory.Create("SayHello"); if(sayHello != null) sayHello.SayHelloTo("zhenyulu"); else Console.WriteLine("Got an Error!"); } } } 现在，MainApp只依赖于接口，不再依赖于其它组件，实现了松耦合。在本例子中，大家可以尝试将配置文件中的IocInCSharp.CnHelloGenerator更改为IocInCSharp.EnHelloGenerator，看看是否输出内容由中文变为了英文。这便是“注入”的效果。 从上面这个例子我们可以看出，通过自定义配置文件和.net中的Reflection技术，我们自己就可以开发Ioc应用，根据配置文件的信息自行 组装相应的对象。但是Reflection编程的技术门槛还是比较高的，并且在实际应用中配置文件的格式、Handler的设计都不是象上面代码那样的简 单。不过幸好我们现在有很多的Ioc容器可供选择，它们都提供了完整的依赖注入方式，并且比自己写代码更加成熟、更加稳定。使用这些框架可以让程序员在三 两行代码里完成“注入”工作。在我们下一个案例中，我们将使用Spring.net实现依赖注入。我们会发现仅仅添加几行代码并更改一下配置文件就可轻松 实现依赖注入。 四、使用Spring.net实现依赖注入 Spring在Java界可是响当当的名字，现在也有.net平台下的Spring框架了，那就是Spring.net。用户可以从http://www.springframework.net/下载到Spring.net的最新版本。本例子中使用的版本为“Spring Interim Build August 15, 2005 ”，并对Spring.Services组件中的Remoting部分做了微小调整，删除了代码中用于输出的部分命令。 Spring.net为我们提供了一种基于配置文件的注入方式，目前Spring.net允许将值注入到属性，也允许将一个工厂绑定到属性，工厂的 产品将注入属性；除此之外，Spring.net还允许将一个方法的返回结果绑定到属性；它还可以在绑定之前强制进行初始化。另外Spring.net还 专门针对.net提供了Remoting以及Windows Service的“注入”方式。Spring.AOP允许完成横切（不过目前是调用的是AopAlliance的代码）。 尽管我对基于配置文件的注入方式仍然有些偏见（我认为它很难Debug、难于理解、没有编译时错误校验、编写效率比较低。另外它还存在安全隐患 ，恶意用户可以借助修改配置文件将恶意代码注入系统。因此，Spring.net在Web开发中应当更具优势），但这并不能掩盖Spring.net的光 芒（据说Castle比Spring.net要好，但目前我还没有尝试过使用Castle）。使用Spring.net，我们只需修改两三行代码，并提供 相应配置文件，就可以轻松实现Ioc。应用Spring.net后，我们的系统依赖关系如下图所示： 　 从图中可以看出，MainApp、SayHello、HelloGenerator之间并不存在任何依赖关系，它们都依赖于抽象出来的接口文件。除 此之外，MainApp还依赖于Spring.net，这使得MainApp可以借助Spring.net实现组件动态创建和组装。 对于原有代码，我们几乎不用作任何调整，唯一需要修改的就是MainApp中的调用方法，代码如下： using System; using System.Configuration; using Spring.Context; namespace IocInCSharp { public class MainApp { public static void Main() { try { IApplicationContext ctx = ConfigurationSettings.GetConfig("spring/context") as IApplicationContext; ISayHello sayHello = (ISayHello)ctx.GetObject("mySayHello"); sayHello.SayHelloTo("zhenyulu"); } catch (Exception e) { Console.WriteLine(e); } } } } 首先我们要添加对Spring.Context命名空间的引用，然后解析配置文件的"spring/context"结点，得到一 IApplicationContext对象（就好比在上一个例子中我们得到的ConfigInfo对象一样），剩下的事情就是向该Context索要相 关的对象了(ISayHello)ctx.GetObject("mySayHello")，其中"mySayHello"由配置文件指定生成方式和注入 方式。 配置文件的内容如下： 注意观察结点，就是由这里定义对象间相互依赖关系的。其中的结点定义了对什么属性执行注入，以及注入的内容是什么（）。大家可以尝试将改为，看一看程序执行结果有什么变化来体会Spring.net的Ioc功能。 如果读者读到这里仍然觉得Ioc没有什么的话，那让我们再来看一个更为复杂的例子。在当前例子中，MainApp通过依赖注入调用了 HelloGenerator的功能，但所有的调用都发生在本地。当前程序是一个地地道道的本地应用程序。现在如果要求在不更改一行代码的情况下，将 HelloGenerator.dll放到另外一台计算机上，MainApp通过远程调用（Remoting）来访问HelloGenerator的功 能。这似乎就有一定的难度了。 这么作并不是没有任何依据，其实Ioc除了可以实现依赖注入外，我们还应当看到它可以将我们从复杂的物理架构中解脱出来，专心于业务代码的开发。系 统开发中关键是逻辑分层。在一个系统不需要Remoting时，开发的系统就是本地应用程序；当需要Remoting时，不用修改任何代码就可以将系统移 植为分布式系统。Ioc使这一切成为可能。Rod Johnson在他的《J2EE without EJB》一书中有着详细的论述，很值得一读。据说该书的中文译本今年九月份出版（呵呵，就是这个月，不过我还没有看到市面上有卖的）。 为了能够更深入的分析在“Remoting”改造过程中我们可能遇到的麻烦，在后续两部分内容中，我们将分别介绍不使用Ioc的Remoting改造以及使用Ioc的改造，并比较两者之间的区别。 五、使用Remoting对原有系统进行改造 如果使用Remoting技术对HelloGenerator进行改造，使其具有分布式远程访问能力，那么在不使用Ioc技术的情况下，我们将会作出如下调整： （1）让HelloGenerator继承自MarshalByRefObject类 如果要让某个对象具有分布式的功能，必须使其继承自MarshalByRefObject，这样才可以具有远程访问的能力。因此我们需要调整EnHelloGenerator和CnHelloGenerator的代码。这里以EnHelloGenerator为例: using System; namespace IocInCSharp { public class EnHelloGenerator : MarshalByRefObject, IHelloGenerator { public string GetHelloString(string name) { return String.Format("Hello, {0}", name); } } } （2）将修改后的HelloGenerator发布出去 在这一步中，我们创建了一个新的Console应用程序RemotingServer，并在其中注册了一个Channel，发布服务并进行监听。代码如下： using System; using System.Configuration; using System.Collections; using System.Runtime.Remoting; using System.Runtime.Remoting.Channels; using System.Runtime.Remoting.Channels.Http; using System.Runtime.Serialization.Formatters; namespace IocInCSharp { public class Server { public static void Main() { int port = Convert.ToInt32(ConfigurationSettings.AppSettings["LocalServerPort"]); try { BinaryServerFormatterSinkProvider serverProvider = new BinaryServerFormatterSinkProvider(); BinaryClientFormatterSinkProvider clientProvider = new BinaryClientFormatterSinkProvider(); serverProvider.TypeFilterLevel = TypeFilterLevel.Full; IDictionary props = new Hashtable(); props["port"] = port; props["timeout"] = 2000; HttpChannel channel = new HttpChannel(props, clientProvider, serverProvider); ChannelServices.RegisterChannel(channel); RemotingConfiguration.RegisterWellKnownServiceType( typeof(EnHelloGenerator), "HelloGenerator.soap", WellKnownObjectMode.Singleton); Console.WriteLine("Server started!\r\nPress ENTER key to stop the server..."); Console.ReadLine(); } catch { Console.WriteLine("Server Start Error!"); } } } } （3）全新的客户端调用代码 为了使得客户端MainApp能够调用到远程的对象，我们需要修改它的代码，注册相应的Channel并进行远程访问。修改后的MainApp代码如下： using System; using System.Configuration; using System.Collections; using System.Runtime.Remoting; using System.Runtime.Remoting.Channels; using System.Runtime.Remoting.Channels.Http; using System.Runtime.Serialization.Formatters; namespace IocInCSharp { public class MainApp { public static void Main() { //建立连接 BinaryServerFormatterSinkProvider serverProvider = new BinaryServerFormatterSinkProvider(); BinaryClientFormatterSinkProvider clientProvider = new BinaryClientFormatterSinkProvider(); serverProvider.TypeFilterLevel = TypeFilterLevel.Full; IDictionary props = new Hashtable(); props["port"] = System.Convert.ToInt32(ConfigurationSettings.AppSettings["ClientPort"]); HttpChannel channel = new HttpChannel(props, clientProvider, serverProvider); ChannelServices.RegisterChannel(channel ); //创建远程对象 ISayHello sayHello = new SayHello(); string RemoteServerUrl = ConfigurationSettings.AppSettings["RemoteServerUrl"]; sayHello.HelloGenerator = (IHelloGenerator)Activator.GetObject(typeof(IHelloGenerator), RemoteServerUrl); sayHello.SayHelloTo("zhenyulu"); } } } 在这段代码中，远程对象的创建是通过(IHelloGenerator)Activator.GetObject(typeof(IHelloGenerator), RemoteServerUrl)实现的。到此为止，我们就完成了对原有系统的Remoting改造。 经过调整后的系统，其组件间相互依赖关系如下图所示： 注意ICommon.dll文件在Client和Server端都有。 在整个调整过程中，我们修改了Server端的EnHelloGenerator以及CnHelloGenerator的代码，Client端的 MainApp也 作了修改，以加入了远程访问机制。那么能不能对原有代码不作任何修改就实现远程访问机制呢？当然可以！不过我们还要请出Sping.net帮助我们实现这 一切。 六、利用Ioc在不修改任何原有代码的情况下实现Remoting 上文我们提到，为了实现对HelloGenerator.dll的分布式调用，我们不得不修改了原有程序的多处代码。那么有没有可能在不动任何原有 代码的情况下，单纯靠添加组件、修改配置文件实现远程访问呢？当然可以。这次我们还是使用Spring.net完成这个工作。 经过调整后的系统组件构成如下图所示： 该方案没有修改“src\Step3”中的任何代码，仅仅通过修改配置文件和添加了若干个组件就实现了远程访问。修改方案如下： （1）使用Proxy模式代理原有HelloGenerator 如果要让某个对象具有分布式的功能，必须使其继承自MarshalByRefObject。但是由于不能修改任何原有代码，所以这次我们只能绕道而 行， 借助Proxy模式代理原有的HelloGenerator。在RemotingServer项目中，我们定义了一个新类 HelloGeneratorProxy继承自MarshalByRefObject，通过委派的方式对原有的HelloGenerator进行调用，代 码如下： using System; namespace IocInCSharp { public class HelloGeneratorProxy : MarshalByRefObject, IHelloGenerator { private IHelloGenerator _helloGen; public IHelloGenerator HelloGenerator { get { return _helloGen; } set { _helloGen = value; } } public string GetHelloString(string name) { if(_helloGen != null) return _helloGen.GetHelloString(name); return null; } } } 仔细观察，我们会发现HelloGeneratorProxy持有一个对IHelloGenerator的引用，该属性是可以Set的，因此我们可 以借助Ioc的威力，通过调整Sping.net的配置文件动态决定远程服务器究竟发布EnHelloGenerator还是 CnHelloGenerator。 （2）发布HelloGeneratorProxy 通过RemotingServer.exe，我们将HelloGeneratorProxy发布出去，客户端实际上调用的是Proxy对象（不用担心，由于“针对接口编程”，客户端只知道它是IHelloGenerator类型对象）。服务器端代码如下： using System; using System.Configuration; using System.Collections; using System.Runtime.Remoting; using System.Runtime.Remoting.Channels; using System.Runtime.Remoting.Channels.Http; using System.Runtime.Serialization.Formatters; using Spring.Context; namespace IocInCSharp { public class Server { public static void Main() { int port = Convert.ToInt32(ConfigurationSettings.AppSettings["LocalServerPort"]); try { BinaryServerFormatterSinkProvider serverProvider = new BinaryServerFormatterSinkProvider(); BinaryClientFormatterSinkProvider clientProvider = new BinaryClientFormatterSinkProvider(); serverProvider.TypeFilterLevel = TypeFilterLevel.Full; IDictionary props = new Hashtable(); props["port"] = port; props["timeout"] = 2000; HttpChannel channel = new HttpChannel(props, clientProvider, serverProvider); ChannelServices.RegisterChannel(channel); IApplicationContext ctx = ConfigurationSettings.GetConfig("spring/context") as IApplicationContext; HelloGeneratorProxy proxy = (HelloGeneratorProxy)ctx.GetObject("myHelloGeneratorProxy"); RemotingServices.Marshal(proxy, "HelloGenerator.soap"); Console.WriteLine("Server started!\r\nPress ENTER key to stop the server..."); Console.ReadLine(); } catch { Console.WriteLine("Server Start Error!"); } } } } 注意其中的几条命令： IApplicationContext ctx = ConfigurationSettings.GetConfig("spring/context") as IApplicationContext; HelloGeneratorProxy proxy = (HelloGeneratorProxy)ctx.GetObject("myHelloGeneratorProxy"); RemotingServices.Marshal(proxy, "HelloGenerator.soap"); 我们使用Ioc向HelloGeneratorProxy注入具体的HelloGenerator对象，并通过 RemotingServices.Marshal(proxy, "HelloGenerator.soap")命令将该实例发布出去。服务器端的配置文件如下： 用户可以尝试将配置文件中更改为，重新启动服务后看看客户端调用结果是什么？ （3）客户端实现技术-1 客户端实现起来要麻烦一些。由于不允许修改MainApp中的任何代码，我们必须能够在合适的时机拦截代码运行并创建远程连接，同时确保在Ioc注 入时注入的是远程对象。所有这些工作Sping.net都考虑的很周到。它提供了depends-on属性，允许在执行某一操作前强制执行某段代码。在客 户端的配置文件中，我们可以看到如下的配置选项： ......... 这表示，当我们初始化mySayHello时，要先去调用ForceInit.dll文件中ForceInit类的Init方法。ForceInit是一个新编写的类，其主要目的就是创建并注册一个用于远程通讯的Channel。代码实现如下： using System; using System.Collections; using System.Runtime.Remoting; using System.Runtime.Remoting.Channels; using System.Runtime.Remoting.Channels.Http; using System.Runtime.Serialization.Formatters; namespace IocInCSharp { public class ForceInit { public static void Init() { //建立连接 BinaryServerFormatterSinkProvider serverProvider = new BinaryServerFormatterSinkProvider(); BinaryClientFormatterSinkProvider clientProvider = new BinaryClientFormatterSinkProvider(); serverProvider.TypeFilterLevel = TypeFilterLevel.Full; IDictionary props = new Hashtable(); props["port"] = 8199; props["name"] = "myHttp"; HttpChannel channel = new HttpChannel(props, clientProvider, serverProvider); //获得当前已注册的通道； IChannel[] channels = ChannelServices.RegisteredChannels; //关闭指定名为MyHttp的通道； foreach (IChannel eachChannel in channels) if (eachChannel.ChannelName == "myHttp") ChannelServices.UnregisterChannel(eachChannel); ChannelServices.RegisterChannel(channel); } } } （4）客户端实现技术-2 剩下的工作就是为mySayHello的HelloGenerator注入远程对象。通常情况下我们需要使用 Activator.GetObject方法调用远程对象，不过Spring.net已经将其封装起来，我们只需修改一下配置文件，就可以确保调用到远程 对象。配置文件对应部分如下： ...... IocInCSharp.IHelloGenerator, ICommon http://127.0.0.1:8100/HelloGenerator.soap 借助Spring.Remoting.SaoFactoryObject，我们轻松实现了远程对象访问，不必书写一行代码。（目前SAO在 Spring.net的实现尚不完整，按照Spring.net帮助手册上的做法，通过配置文件只能实现客户端访问远程对象，还做不到服务器端发布远程对 象） （5）使用AOP拦截调用 Sping.net目前已经实现AOP功能，我们可以很容易的对方法进行拦截和调用。需要做的工作就是设计相应的Interceptor，然后修改 配置文件。目前Sping.net使用的AOP功能是AopAlliance的实现，因此代码编写时命名空间引用让人感觉多少有些别扭，不是以Sping 开头。我编写的MethodInterceptor代码如下： using System; using AopAlliance.Intercept; namespace IocInCSharp { class MethodInterceptor : IMethodInterceptor { public object Invoke(IMethodInvocation invocation) { Console.WriteLine("Before Method Call..."); object returnValue = invocation.Proceed(); Console.WriteLine("After Method Call..."); return returnValue; } } } 在方法调用前打印"Before Method Call..."，在方法调用后打印"After Method Call..."。剩下的工作就是修改配置文件，将其应用到相应的方法上。配置文件片断如下： ...... MethodAdvice 通过以上操作，我们在没有修改任何原有代码的情况下，让原有系统实现了远程分布式访问。 请大家访问示例代码的“bin\Step5"目录，下面有3个子目录：Server、Client、WithoutRemoting。首先运行 Server目录下的RemotingServer.exe，然后运行Client目录下的MainApp.exe进行远程调用。系统通过 Remoting完成远程调用。关闭所有程序后，进入到WithoutRemoting目录，里面有个Readme.txt文件，按照操作步骤将文件： ..\Server\HelloGenerator.dll ..\Client\MainApp.exe ..\Client\ICommon.dll ..\Client\SayHello.dll ..\Client\Spring.Core.dll ..\Client\log4net.dll 　 拷贝到该目录，再次运行MainApp.exe，你会发现它是一个地地道道的本地应用程序！本地与远程唯一的区别就是配置文件的不同以及增加了几个其它的DLL。这正式我们这个示例的价值体现。 到此为止，我们完成了对Ioc应用的一系列模拟。Ioc写得多一些，AOP写得少了点。欢迎大家批评指正。
.NET实现微服务架构
05-08
微服务架构（Microservices Architecture）是将系统拆分为多个服务，俗称为应用服务。应用服务实现单一、具体的业务应用功能，支持独立部署维护，多个应用服务构建成系统。应用服务之间通过轻量级通信框架进行，并且支持应用服务用不同技术或者平台实现。
Net分布式系统之五：微服务架构
cxu123321的博客
06-24 4708
Net分布式系统之五：微服务架构 　　因工作较忙，抽时间将框架遇到的问题和框架升级设计进行记录。 一、背景&问题 　　之前框架是一个基于SOA思想设计的分布式框架。各应用通过服务方式提供使用，服务之间通信是RPC方式调用，具体实现基于.NET的WCF通信平台。框架存在如下2个问题： 　　1、高并发处理能力不足。一当高并发请求，可能出现多个服务待定处理，导致整个系统出现瓶颈。...
C#学习之.NET系统架构（一）
m0_46637217的博客
01-15 1392
前言： C#语言不可以单独使用，必须和.Net Framework一起使用。C#编程语言以及其编译器专门用于.NET平台。这也说明C#说编写的代码总是在.Net Framework中运行。 结论：C#的特定语言功能取决于.NET的功能，或依赖于.Net基类。 1. C#和.NET的关系 C#是一门比较新的编程语言，C#语言的特点： 专门与Microsoft的.Net Framework一起使用而设计的。 基于现代面向对象的编程语言 注意： .NET Framework是一个功能非常丰富的平台，.
我们为什么需要DTO(数据传输对象)
Truong的专栏
08-02 869
DTO即数据传输对象。之前不明白有些框架中为什么要专门定义DTO来绑定表现层中的数据，为什么不能直接用实体模型呢，有了DTO同时还要维护DTO与Model之间的映射关系，多麻烦。 然后看了这篇文章中的讨论部分才恍然大悟。 摘两个比较有意义的段落。 表现层与应用层之间是通过数据传输对象（DTO）进行交互的，数据传输对象是没有行为的POCO对象，它 的目的只是为了对领域对象进行数据封装，实现层
.NET 框架简介
热门推荐
大鹏
07-13 1万+
初学.NET肯定会有一系列的疑问，比如（以下为自己的疑问）： 　　1)        何为. NET框架，它都包含哪些东西？ 　　2)        程序集是什么，它是如何在CLR(通用语言运行时)中运行的？ 　　3)        C#与VB.NET同属于.NET平台，它们之间的根本联系和区别，为何他们之间的程序集能互相调用（如果创建一种新型的面向. NET的语言，要遵循什么）？ 　　想
企业应用系统架构与设计模式 共49页.pptx
11-15
"该资源是关于企业应用系统架构与设计模式的PPT，由林耀珍技术总监分享，主要探讨了.NET技术在企业系统中的应用，包括系统架构、设计模式等多个方面。" 在企业的信息技术领域，系统架构和设计模式扮演着至关重要的...

“相关推荐”对你有帮助么？

  • 非常没帮助
  • 没帮助
  • 一般
  • 有帮助
  • 非常有帮助
提交
评论
添加红包

请填写红包祝福语或标题

个

红包个数最小为10个

元

红包金额最低5元

当前余额3.43元 前往充值 >
需支付：10.00元
成就一亿技术人!
领取后你会自动成为博主和红包主的粉丝 规则
hope_wisdom
发出的红包
实付元
使用余额支付
点击重新获取
扫码支付
钱包余额 0

抵扣说明：

1.余额是钱包充值的虚拟货币，按照1:1的比例进行支付金额的抵扣。
2.余额无法直接购买下载，可以购买VIP、付费专栏及课程。

余额充值