Electronic Joint Business

Solution for E-Business

微软框架

.NET 编译平台 (Roslyn) 概述

文章评价:
一直以来,编译器都按黑盒的方式运作 — 这头放入源代码,中间部分施展魔法,在另一头就会生成目标文件或程序集。当编译器施展魔法时,它建立了对代码的深刻理解,但这些知识除了实现编译器的巫师外,旁人无法掌握。一旦生成编译输出,这些信息就被彻底忘却。几十年来,这种方式一直运作良好,但现在却不能满足需要了。

如今为了提高生产力, 人们越来越依赖于集成开发环境(IDE)所提供的智能感知、重构、智能重命名、 “查找所有引用” 和 “转到定义” 等功能。我们用代码分析工具来改善代码质量,用代码生成器来协助代码构建。想要让这些工具更聪明,就需要它们能更多地访问编译器,同时也需要对编译器中深厚的代码处理知识有更多的了解。

这就是 .NET 编译器平台(“Roslyn”)的核心使命:打开黑盒让工具和用户可以分享编译器处理代码时的大量信息。与 “源代码—目标文件”的直译方式不同,Roslyn 使编译器成为平台,这意味着工具和应用程序可以通过 API 来处理代码相关的任务。

将编译器过渡到平台,这大大降低了构建代码相关(code focused)工具与程序的门槛,在许多方面推动了创新,包括:元编程、代码生成、代码转化、C#\VB 的交互式使用、领域特定语言内嵌 C#\VB 等等。

在 .NET 编译器平台 (“Roslyn”) SDK 预览版中包括了最新的语言对象模型,可用于代码生成、代码分析与重构。我们还包括了一些 API 草稿,以便在后续的版本中实现支持脚本、C#\VB的交互式使用。本文是对 .NET 编译器平台(“Roslyn”)的概念性描述,更多情况可以参考预览版 SDK 中的演示与示例。

>>> 阅读全文

 

, , , , , , , ,

如何创建灵活的可重用的 WCF 服务

简介
你也许知道,要创建可靠的多层应用程序来说,设计和创建一个灵活且可重用的服务层是必不可少的。在这篇文章中,我们要讨不同的构建服务层的方法及其利弊。您将学习一些可以帮助构建可重用服务的设计模式,我们还会演示如何用开源的 Xomega 框架实现 WCF 服务的。

我们还将讨论在 Silverlight 中使用 WCF 的挑战,以及解决这些挑战的解决方案解决。

架构概览
在开始设计你的服务层的时候,你所面对的第一个问题是你的服务层是完全无状态的还是可能会是有状态的?

无状态服务的利与弊
对于完全无状态的服务,每个请求是完全相互独立的,所以有其优势,但不很适合建立灵活的、 可重复使用的服务,我们一会再加解释。无状态服务的好处是有很强的可扩展性和较低的资源占用率,如内存消耗和线程使用。您可以通过服务器集群对服务进行负载平衡,而且每个服务器能够独立地处理任何请求,而无需占用任何内存来存储状态,在处理完请求之后,就可以释放如线程或数据库连接等资源。

但是,不利的方面是你将不得不随每个请求传递整个状态。如果状态总是比较小,如读取/查询操作或作为一个工作单元执行的简单更新,这不可能是一个问题。在大型系统和企业应用程序,总是需要多个级别的验证,才能保存数据,但用户状态可能包含大量跨多个对象的编辑。设计一种服务,能把所有的用户编辑单个请求可以在这种情况下,是一个极具挑战性的任务,您可能需要设计一个单独的服务或操作对于每个不同的方案,这将使您的服务不重用,最终可能导致维护恶梦。

>>> 阅读全文

 

, , ,

创建基于模板的WPF定制控件

WPF可以创建两种控件,它们的名字也很容易让人混淆:用户控件(User Control)和定制控件(Customer Control),之所以如此命名,是因为用户控件更面向控件的“使用者”,以方面他们利用现成的控件组合成新的控件,而定制控件,更便于定制化(Customization),方便创建有别于现有控件的定制控件。

定制控件提供了行为和表现完全分离的开发模式,具有很高的灵活性,当然,也更难一些。这里我们通过创建个简单的搜索控件来看看如何开发定制控件:

首先我们创建一个WPF应用,在同一个solution里,再添加一个用户WPF控件库。
系统会自动在控件库里创建一个UserControl1.XAML,这个文件可以直接删除。在WPF控件库里添加一个新的项目,注意:应该选择定制控件而不是用户控件,如图:

>>> 阅读全文

 

, ,

深入MEF框架 (二)契约与导入、导出

契约
所谓的契约即一种约定,或者叫做规则。在上一节的例子中,在对象 StringProvider 中就定义了一个导出部件属性(Output),并为其指定了通信契约为“Message”。这里的 “Message” 就是种约定,即:在需要使用到这个属性的地方,都可以利用 [Import] 引用契约(“Message”)进行部件的导入。

在 MEF 中可组合部件并非是直接依赖于彼此,它们都依赖于一个契约,也就是一个标示字符串。每个导出都有一个契约,而导入需要声明它需要依据哪个契约。容器通过使用契约信息来匹配导入和导出。如果没有指明契约,MEF 默认使用类型的全限定名作为契约。实际上这一步可以简单的理解为“依赖注入”,本质上就是对象的实例初始化过程。如果在导出中指定了类型,MEF 则会使用该类型全限定名。

注意:对于非基本类型,默认情况下,应该使用类型而不建议使用字符串在作为契约。虽然契约可以是字符串,但可能会导致一些混淆。比如 “Sender” 这个契约可能与另一个实现里的 “Sender” 重名。因此如果使用字符串作为契约,最好遵循名称空间的写法并带上公司的名字,比如”Contoso.Exports.Sender”。

下面的代码中出现的所有导出契约都是等价的。

namespace MEF.Examples{   
    [Export]   
    public class Exporter {}  
 
    [Export(typeof(Exporter))]  
    public class Exporter{}   
    
    [Export("MEF.Examples.Exporter")]   
    public class Exporter{}   
}

可组合部件的普遍模式是采用接口或者抽象类型来作为契约,而不是具体类型。这样导入部件完全与其导入的导出部件的某个特定实现解耦从而分离关注。比如如下的代码中,有两个类都导出了IMessageSender。Notifier类导入一组IMessageSender,并调用其中每一项的Send()方法。现在新的信息发送器可以很容易的被添加到系统中去。

>>> 阅读全文

 

, ,

深入MEF框架 (一) 基本概念

文章评分:

为什么需要 MEF?
近年来,用于实现可扩展性的框架越来越受到人们的重视,为此已经存在许多依赖注入框架来解决应用的扩展性问题,比如 Eclipse 的 OSGI 实现以及 Java 的 Spring 等等。在 Microsoft 的平台上,.NET Framework 自身内部包含组件模型和 System.Addin,此外还有不少开源解决方案,包括 SharpDevelop 的 SODA 体系结构和“控制反转”容器(如 Castle Windsor、Structure Map、Spring.Net 以及 Unity )。为什么我们还需要 MEF 呢?

在 Microsoft 看来,这些方案有些过于庞杂(比如 OSGI ),有些则需要开发人员完成许多额外配置工作(比如 Spring ), MEF 试图秉承这些解决方案的优点,尝试解决刚才所提及的令人头痛的问题。 MEF 有两个优点:

  • 第一,MEF是开源项目,其源代码在Codeplex上可以下载,
  • 第二,MEF 是第一个随 CLR 发布的扩展性管理的框架,而且在 Visual Studio 和 Silverlight 中被广泛应用。

官方给 MEF 下的定义:Managed Extensibility Framework(MEF)是 .NET 平台下的一个扩展性管理框架,它是一系列特性的集合,包括依赖注入( DI )以及 Duck Typing 等。MEF 为开发人员提供了一个工具,让我们可以轻松的对应用程序进行扩展并且对已有的代码产生最小的影响,开发人员在开发过程中根据功能要求定义一些扩展点,之后就可以使用这些扩展点与应用程序交互;同时MEF让应用程序与扩展程序之间不产生直接的依赖,这样也允许在多个具有相同的扩展需求之间共享扩展程序。

概念
简单说一下 MEF 的工作原理,MEF 的核心包括一个 catalog(目录)和一个 CompositionContainer(组合容器)。catalog 用于发现扩展,而 container 用于协调创建和梳理依赖性。MEF 组合模型的核心是组合容器,该容器包含所有可用的部件并执行组合操作(即,将导入和导出配对)。见下图。

>>> 阅读全文

 

, , , ,