思归呓语

衣带渐宽终不悔,为伊消得人憔悴
随笔 - 409, 评论 - 2969, 引用 - 245

导航

关于

标签

每月存档

最新留言

广告

【第1页/共28页,409条】
首页
前页
1
...
2009年05月29日

【原文地址】POCO in the Entity Framework : Part 2 – Complex Types, Deferred Loading and Explicit Loading
【原文发表日期】 28 May 09 09:03 AM

在上星期的贴子《POCO Experience in Entity Framework》 (实体框架中的POCO体验)中,我讨论了Entity Framework 4.0中POCO支持的基本。在这个贴子里,我将讨论与POCO相关的另外几个方面。

复杂类型(Complex Types)

POCO中的复杂类型支持跟常规的基于EntityObject的实体中的复杂类型支持一样。你要做的就是将它们声明为POCO类,然后在你的POCO实体中使用和声明基于它们的属性。

作为例子,这里是一个InventoryDetail复杂类型,代表我的Product实体的一个部分:

public class InventoryDetail
{
public Int16 UnitsInStock { get; set; }
public Int16 UnitsOnOrder { get; set; }
public Int16 ReorderLevel { get; set; }
}

把我的Product类修改成包含一个这个类型的属性,用来组合几个有关库存细节的字段:

public class Product
{
public int ProductID { get; set; }
public string ProductName { get; set; }
public int SupplierID { get; set; }
public string QuantityPerUnit { get; set; }
public decimal UnitPrice { get; set; }
public InventoryDetail InventoryDetail { get; set; }
public bool Discontinued { get; set; }
public Category Category { get; set; }
}

然后你可以做你以前对复杂类型所能做的一切,这是一个查询的例子:

var outOfStockProducts = from c in context.Products
where c.InventoryDetail.UnitsInStock == 0
select c;

 

你可以看到,POCO中的复杂类型支持用起来非常直截了当。但在POCO中使用复杂类型支持时,你需要记住几件事情:

  1. 你必须将复杂类型定义为类(class),结构体(struct)是不支持的。
  2. 在你的复杂类型类中,你不能使用继承。

既然在讨论复杂类型,我想我要提一下另外一件事,你知道Visual Studio 2010中的实体框架设计器支持复杂类型的声明么?

在Visual Studio 2008中,你只能手工将复杂类型的声明加到CSDL中去,但随着Visual Studio 2010中的设计器中对复杂类型支持的推出,这一切都成了历史。

image

更酷的是,因为Visual Studio 2010支持多定向(Multi-Targeting),你可以在开发针对.NET Framework 3.5,使用了Entity Framework 3.5的应用中也使用这个功能!

延迟/懒式装载

在我2个星期前发表的《延迟装载初览》一文中,我提到了实体框架现在支持延迟装载了。默认的、代码生成的基于EntityObject的实体类型将提供延迟装载,自然毫不奇怪。如果你想知道POCO对象中是否也支持延迟装载,那么我想,你会很高兴地知道,你在POCO中也能得到延迟装载支持。

为在POCO实体中使用延迟装载支持,你需要做2件事情:

  1. 将你想要懒式装载的属性声明为virtual,这些属性可以是任何实现了ICollection<T> 的集合类,或者它们可以是代表了1/0..1 关系的引用。

例如,这里是更新过的Category实体类的部分代码,我将其改成支持延迟装载了:

public class Category
{
public int CategoryID { get; set; }
public string CategoryName { get; set; }
public string Description { get; set; }
public byte[] Picture { get; set; }
public virtual List<Product> Products { get; set; }
...

     2.   在上下文中启用延迟装载选项:

context.ContextOptions.DeferredLoadingEnabled = true;

 

这就行了,你现在就将得到POCO类型的自动延迟装载,而不用做任何其他什么事情。

那么这玩意到底是怎么工作的,底层是怎么进行的?

这玩意能工作的原因是因为,在我将集合类型的属性标记为virtual后,这允许实体框架在运行时为我的POCO类型提供一个代理(proxy) 实例,正是这个代理实现了自动的延迟装载。该代理实例是基于一个继承自我的POCO实体类的类型,所以你提供的所有功能都被保留下来了。从开发人员的角度来看,即使延迟装载或许是个需求,这也允许你编写透明持久性的代码。

如果你在调试器中检查实际的实例时,你会看到该实例的底层类型与我原先声明的类型是不同的:

image

虽然实体框架尽力以最小的摩擦提供自动的延迟装载,但在处理你想要添加或附加手工生成的实例时,或者当你序列化/发序列化实例时,这是你需要知道的事情。

为POCO实体手工生成代理实例

为了允许可以添加或附加的代理实例的生成,你可以使用ObjectContext上的CreateObject工厂方法来生成实体实例:

Category category = context.CreateObject<Category>();

 

要把这个记住,在生成你想要用于实体框架的实例时,要使用CreateObject

用“变动跟踪代理(Change Tracking Proxies)”来提供更有效的变动跟踪

到目前为止,我们讨论过的标准POCO实体都依赖于基于快照(snapshot)的变动跟踪,即,实体框架会保管实体变动之前的值和关系的快照,这样,在保存(Save)时,可以与当前的值做比较。但这个比较的花销是相当大的,如果跟基于EntityObject的实体的变动跟踪的方式相比的话。

还有另外一种类型的代理,它允许你在使用POCO实体时得到比较好的变动跟踪性能。

如果你熟悉IPOCO接口,你知道IEntityWithChangeTracker是要求你在类中实现、来向实体框架提供变动通知的接口之一。

变动跟踪代理从你的POCO实体类继承而来,在运行时给你提供这个功能,而不要求你自己实现IPOCO接口。

从许多方面讲,用这种方式的话,你是鱼与熊掌都兼得了:你得到了POCO类的透明持久性,在变动跟踪方面你也得到了EntityObject / IPOCO 的性能。

为了得到变动跟踪代理,基本的规则是,你的类必须是公开的,非抽象的或者非密封的(non-sealed)。你的类对所有要持久的属性都必须实现公开的virtual getters/setters。最后,你必须将基于集合的关系导航属性严格声明为ICollection<T>。它们不能是具体的实现或者继承自ICollection<T>的另外的接口(与延迟装载代理有所不同)。

这里是我的Product POCO类的例子,它将在运行时给我提供更有效的基于代理的变动跟踪:

public class Product
{
public virtual int ProductID { get; set; }
public virtual string ProductName { get; set; }
public virtual int SupplierID { get; set; }
public virtual string QuantityPerUnit { get; set; }
public virtual decimal UnitPrice { get; set; }
public virtual InventoryDetail InventoryDetail { get; set; }
public virtual bool Discontinued { get; set; }
public virtual Category Category { get; set; }
}

再说一遍,要记住,如果你要将实体加到或附加到上下文的话,你必须使用CreateObject来生成代理实例。但不依赖代理的纯粹的POCO实体和基于代理的实体可以共处。你只有在涉及基于代理的实体时才需使用CreateObject。

如果我想在同个POCO类型中同时启用延迟装载和更好的变动跟踪,该怎么办?

这两个东西不是互相排斥的,你不必在延迟装载代理和变动跟踪代理间做选择。如果你想要延迟装载,以及有效的变动跟踪,你只要按照变动跟踪代理的规则办,以及启用延迟装载选项。变动跟踪代理会给你提供延迟装载,如果延迟装载选项是启用了的话。

显式装载

这个延迟装载的功能确实很棒,但你们中很多人大概想要完全控制你是如何装载相关实体的吧。你甚至会选择走纯粹的POCO之路,而不诉诸于任何自动代理生成能给你提供的功能。

这是完全可以接受的,(在很多情形下也许是更好的方法),你可以使用显式关系装载,对你是如何在数据库中查询数据的做完全的控制。

在POCO中做显式装载,有2个选项:

一个是使用 ObjectContext.LoadProperty ,设置你想要装载的导航属性的名称:

context.LoadProperty(beveragesCategory, "Products");

这是可行的,但你可以看出来,这并不类型安全(type safe)。如果我没有正确的导航属性的名称的话,我会得到一个运行时异常。

你们中的一些人大概更喜欢这个:

context.LoadProperty(beveragesCategory, c => c.Products);

我可以使用lambda表达式来指定我想要显式装载的属性,这提供了更好的类型安全。

上面是我计划在这第二个贴子里讨论的所有的内容了。但以后还会有更多内容,在这个系列的最后一篇里,我们将讨论在处理纯POCO(非代理化的)实例以及在你的对象图和对象状态管理器(Object State Manager)间保持一致时需要知道的几件事情。我们也会讨论你也许想要知道的SaveChanges方法的多个变种。

与此同时,请看一下我更新过的样例代码,其中包括了我们在本贴里讨论过的一些东西。

Faisal Mohamood
Entity Framework的Program Manager

posted on 2009-05-29 14:12:55 by saucer  评论(3) 阅读(2285)

 
2009年05月28日

【译者按】 Entity Framework 1.0 发布也有一段时间了,但感觉用的人很少。其中一个很大的原因,也许就是不支持POCO。要知道,Entity Framework 1.0的做法是让你的实体从EF的基类继承而来,这对很多人,特别是崇尚DDD的人来说,那是一副难以下咽的药啊。曾有微软开发人员提供了一个 POCO Adapter,但那究竟不是正规的做法。Visual Studio 2010 和 .NET 4.0 提供了许许多多的新特性,真是让人激动,向往,大有一种回到.NET 1.0 刚出来时的感觉。春天啊(应该是夏天啊),你终于回来了(虽然早晨/晚上还是unseasonably冷)。其中的Entity Framework 4.0版本将提供POCO支持,对很多人来说,这是开始使用Entity Framework的时候了。ADO.NET 团队博客上贴出了一些关于EF和POCO的贴子,非常值得一读。

【原文地址】POCO in the Entity Framework: Part 1 - The Experience
【原文发表日期】 21 May 09 05:46 PM

上个星期,我在《POCO初览》中提到了POCO实体支持是我们加到Entity Framework 4.0中的新功能之一。这个星期,我要对Entity Framework 4.0中POCO支持的细节进行深入讨论。

要讨论的东西很多,包括

  • Entity Framework 4.0中总的POCO体验
  • POCO的变化跟踪
  • 关系修整
  • 复杂类型
  • 延迟(懒式)装载和显式装载
  • 最佳实践

在这个贴子中,我将主要着重于总的体验,这样,你可以马上启用Entity Framework 4.0中的POCO支持。我将使用一个简单的例子做示范,这样,你可以看到在Entity Framework 4.0中使用POCO的感觉。我将使用Northwind数据库,在随后的贴子中,将继续建立在这个例子的基础之上。

第一步: 创建模型,关闭默认的代码生成

虽然POCO允许你以透明持久化的方式编写自己的实体类,但还是有必要“接入”持久性和EF元数据,这样你的POCO实体可以从数据库中复原,以及持久化到数据库中。为实现这个,你还是需要使用实体框架设计器创建一个实体数据模型(Entity Data Model),或者提供跟你在Entity Framework 3.5中生成的完全一样的CSDL, SSDL 和 MSL 元数据文件。所以,首先,我将使用ADO.NET实体数据模型向导(Entity Data Model Wizard)来生成一个EDMX。

image

  1. 创建一个类库项目来定义你的POCO类型,我将其命名为NorthwindModel。这个项目与持久性毫不相关,对实体框架没有依赖性。
  2. 创建一个类库项目,它将包含与持久性相关的代码,我将其命名为NorthwindData。这个项目除了对NorthwindModel项目有依赖外,还对实体框架(System.Data.Entity)有依赖。
  3. NorthwindData 项目中添加新项,加一个名为“Northwind.edmx ”的ADO.NET实体数据模型(这么做将自动在项目中添加对实体框架的依赖)。
  4. 选择“从数据库生成”,给Northwind数据库建造模型
  5. 暂时只选CategoriesProducts这两个你感兴趣的表到你的实体数据模型中。

至此,生成了可以为我所用的实体数据模型,但在开始编写代码前,还有最后一步:关闭代码生成。毕竟你感兴趣的是POCO啊,请去除负责从Northwind.edmx生成基于EntityObject代码的Custom Tool(自定义工具)属性,这将关闭你的模型的相应代码生成。

image

现在,我们可以编写POCO实体了。

第二步: 编写你的POCO实体

我将为Category和Product编写简单的POCO实体,这些类将加到NorthwindModel项目中去。注意,我在这里展示的,不应该看成是最佳实践,这里的意图只是示范可以工作的最简单的例子。在以后我们将根据需要将对这些例子进行扩展和定制,之后建立在其基础之上,使用RepositoryUnit of Work模式做进一步的扩展。

这里是Category实体的样例代码:

    public class Category
    {
        public int CategoryID { get; set; }
        public string CategoryName { get; set; }
        public string Description { get; set; }
        public byte[] Picture { get; set; }
        public List<Product> Products { get; set; }
    }

注意,在模型中我既为标量字段定义了属性,也定义了导航属性。模型中的导航属性(Navigation Property)转换成了List<Product>。

类似地,Product实体可以这样编写:

    public class Product
    {
        public int ProductID { get; set; }
        public string ProductName { get; set; }
        public int SupplierID { get; set; }
        public string QuantityPerUnit { get; set; }
        public decimal UnitPrice { get; set; }
        public Int16 UnitsInStock { get; set; }
        public Int16 UnitsOnOrder { get; set; }
        public Int16 ReorderLevel { get; set; }
        public bool Discontinued { get; set; }
        public Category Category { get; set; }
    }

在这个例子中,因为其间的关系,一个Product只允许属于一个Category,因此我们有一个对Category的引用(而不象Category中的导航属性,是一个List<T>集合)。

第三步: 编写你的实体框架上下文

为把所有这些东西结合在一起,我所要做的最后一件事情是,提供一个上下文实现(就象使用默认的代码生成时你得到的ObjectContext实现一样)。上下文(context)是把持久化意识带进你的应用的胶水(glue),它允许你编写查询,将实体复原,以及将变化存回到数据库中去。该上下文将是NorthwindData项目的一部分。

为简单起见,我将我们的上下文类包括在了包含实体类型的同个类库项目中了,但在我们讨论诸如Repository Unit of Work等模式时,我们将做这样的设置,即,你将拥有一个纯粹的POCO类库,不带任何一丝与持久性相关的东西。

这里是针对我们场景的简单的上下文实现:

public class NorthwindContext : ObjectContext
    {   
        public NorthwindContext() : base("name=NorthwindEntities", 
"NorthwindEntities") { _categories = CreateObjectSet<Category>(); _products = CreateObjectSet<Product>(); } public ObjectSet<Category> Categories { get { return _categories; } } private ObjectSet<Category> _categories; public ObjectSet<Product> Products { get { return _products; } } private ObjectSet<Product> _products; }

注意,ObjectSet<T> 是Entity Framework 4.0中引进的一个特殊的ObjectQuery<T>。

就这么简单!现在你有了纯粹的POCO实体,一个简单的上下文,允许你编写象这样的查询:

    NorthwindContext db = new NorthwindContext();
 
    var beverages = from p in db.Products
                    where p.Category.CategoryName == "Beverages"
                    select p;

从数据库中复原的实体是纯粹的POCO实体,你可以对这些实体做变动,将变动保存到数据库中,跟平常的EntityObjectIPOCO实体非常类似。你将得到实体框架提供的所有服务,唯一的区别是,你现在使用的是纯粹的POCO实体。

就我们的简化了的例子而言,尚有无数改进的可能性。但在那之前,我想先把一些基本的问题解决掉。

在使用POCO之前我需要一个实体数据模型么?

是的,Entity Framework 4.0中的POCO支持只是去除了在你的实体类中带特定于持久性的关注的需求而已。但还是需要你提供CSDL/SSDL/MSL (总称EDMX)元数据,这样实体框架才能够将你的实体和元数据结合起来,以允许你访问数据。我们还在另外开发一个东西,它允许你做真正的“代码优先(code-first)”的开发,而不需要预先定义好的EDMX模型。这个功能的社区预览版将在几个月内在网上发布,一有机会我们就会将其加入实体框架。一如既往,你的反馈对我们极其有用。

我始终都只能手写这些实体和上下文么?

不, Entity Framework 4.0中有一个非常强大和灵活的代码生成机制,该机制是基于T4之上的(Alex曾在这里的博客上讨论过)。你可以提供你自己的模板,允许你按照你自己选择的方式建造实体。我们还在努力,以提供一些标准的模板,可为你生成POCO实体。

使用POCO实体时,元数据是怎么映射的?

在Entity Framework 3.5中,基于EntityObjectIPOCO的实体都是依赖着使用映射特性(attributes),对实体类型和属性进行修饰和映射到概念性模型中对应的元素的。Entity Framework 4.0 引入了基于约定(convention)的映射,以允许不用显式的修饰,就可将实体类型,属性,复杂类型和关系映射到概念性模型。一个简单的规则是,在你的POCO类中使用的实体类型名称,属性名称,和复杂类型名称必须匹配那些在概念性模型中定义了的相应名称。命名空间的名称不在考虑之中,类中的命名空间定义和概念性模型中的命名空间定义不必相符。

我的实体类中的所有属性都需要有公开的getters和setters么?

你可以在你的POCO类型的属性上使用任何访问控制修饰符(access modifier),只要被映射的任何属性都不是虚拟的,以及你不需要局部信任(partial trust)支持。在局部信任下运行时,对你的实体类的访问控制修饰符的可见性有一些特定的要求。我们将对在涉及局部信任时,所支持的完整的访问控制修饰符集提供详细的文档。

对基于集合的导航属性都支持哪些集合类型?

任何属于ICollection<T>的类型都是支持的。如果你对ICollection<T>类型的字段不以具体的类型初始化的话,那么从数据库中复原实体集合时, 将提供List<T>

我可以有单向的关系么?例如,我想在我的Product类中有一个 Category 属性,但在Category类中我不想要一个Products集合。

是的,这是支持的。唯一的限制是,你的实体类型必须反映模型中所定义的东西。如果你不想拥有对应于关系的某一边的导航属性的话,那么你需要从模型中将其完全剔除。

POCO支持延迟(懒式)装载么?

是的,POCO是通过使用代理类型来支持延迟(懒式)装载的,这些代理类型是在你的POCO类之上提供自动的懒式装载行为的。在讨论到延迟装载时,我们会对此做详述,在那之前,知道一下我们也支持通过使用“Include”来实现的早期装载(eager loading),象这样:

var beverageCategory = (from c in context.Categories
.Include("Products") where c.CategoryName == "Beverages" select c).Single();

如果我要使用延迟(懒式)装载的话,我不用这么做, 在讨论代理时我们会对此进行讨论。

修整(fix-up)关系

要了解有2种类型的修整:1)查询时的修整, 2) 对你的实体/关系进行改动时的修整。

查询时的修整

查询时的修整是在同一个ObjectContext上使用不同的查询来装载相关的实体时发生的。例如,如果我查询了一个分类实例“Beverages(饮料)”,之后又查询一个产品实例“Chai”(是在Beverages分类中的),我想要chai.Category 指向Beverages分类实例,不用我做额外的工作。

这在今天是自动的,而且已经工作。

对你的实体/关系进行改动时的修整

这是在添加/去除与另一个实体相关的实体或者改变关系时两个实体间的关系修整。设想一下这样的例子:在我创建一个名叫“Diet Chai”的新产品时,我想要将其与Beverages 分类相关联。

在Entity Framework 4.0 Beta1 中,在这种情形下,POCO实体得不到自动的关系修整。在处理实体间的关系变动时,你需要确认你的POCO类型包含了在关系两头正确处理关系修整的逻辑。

例如,在我的Northwind例子中,我在Category上定义了如下的方法,以支持添加/去除订单。

        public void AddProduct(Product p)
        {
            if (Products == null)
            {
                Products = new List<Product>();
            }
 
            if (!Products.Contains(p))
            {
                Products.Add(p);
            }            
            
            p.Category = this;
        }

总的来说,使用象这样的模式来支持添加/去除相关项,要比使用关系集合来添加/去除相关实体为好。你还可以选择将实际由EF支持的集合的getter/setter变成私有或内部访问控制,来支持更为细颗粒的访问,但就象前面提到的那样,其中一些东西取决于你是否需要局部信任支持这样的需求。

我们在这个“简短的综述”中对总的POCO体验做了一番讨论。要讨论的东西还有很多很多,下个星期我将继续这个讨论。与此同时,请看一下附件中的完整解决方案,如果你对我们在这里讨论的所有概念的相应例程代码感兴趣的话。请记住,你必须在运行这个例程的机器上安装一个本地Northwind数据库。

在下一个贴子中,我们将看一下复杂类型,变化跟踪,代理,懒式装载和早期装载。在那之前,请阅读一下MSDN这里的关于POCO的文档,以了解Entity Framework 4.0中的POCO支持的细节。

请告知我们你们的想法!

Faisal Mohamood
Entity Framework的Program Manager

posted on 2009-05-28 14:19:46 by saucer  评论(1) 阅读(2740)

 
2009年01月09日

大家都知道,Windows 7 beta(7000)已于昨天推出,参与微软Connect,以及有MSDN和TechNet订阅的都可以下载了。

下载完后,决定不是全新安装,而是选择了从先前安装的Windows 7的6801版本升级,没想到安装花了很长的时间。只好安慰自己,假如全新安装的话,加上安装办公软件+抗毒软件+以及小孩安装的各种软件,总的时间恐怕会更长。

安装完了,赶紧安装第一个补丁,KB961367,这修复了Media Player12的一个缺陷,因为它会在某些特别的情形下剪去某些mp3文件的前面几秒。呵,因为这是小孩的机器,我可不愿为坏掉了的mp3文件负责。

运行Norton的更新和扫描,居然蓝屏死机了,又试了一次,还是一样。

界面有了几个变动,譬如新的taskbar和Jump list,细节就不谈了。

用的时候感觉很平滑,响应比前面的那个版本要快,性能比以前好了。

【更新】微软刚公开了beta测试,任何人都可以在下面这个链接下载(但限于前面二百五十万位):

Welcome to the Windows 7 Beta Customer Preview Program
http://technet.microsoft.com/en-us/evalcenter/dd353205.aspx

【最新更新(1月11日)】因为下载的人太多,导致服务器运行缓慢,微软一度推迟了下载。在做了调整之后,现在恢复了下载。同时取消了二百五十万份下载数的限制,但只开放下载2个星期(到1月24日为止)。上面的链接依然有效,还有这个链接:

Download the Windows 7 Beta
http://www.microsoft.com/windows/windows-7/beta-download.aspx

 

posted on 2009-01-09 23:50:17 by saucer  评论(0) 阅读(3752)

 
2008年12月24日

想玩Windows 7很久了,而且从网上的评论来看,大家对Windows 7的评论都非常正面。但因为没有参加PDC,没能得到带Windows 7的碟子。最近MVP的邮件列单上说有多余碟子赠送,就去信说想要一份,没想到很快就寄来了。在这里,要感谢微软中国MVP部门,特别是MVP Lead Sisley。

拿到碟子后,迫不及待地在Virtual PC上装了一份,但没有硬件加速,感觉不是很过瘾。

小孩的Dell机器(04年购置的)不久前被一个病毒所扰,修复后很多软件都无法用了,一直吵着要重新安装系统。我想,反正是重装,就装Windows 7,让小孩做beta测试人员吧。

安装比较顺利,而且好像安装的时间也比较短。但可惜,系统居然不认识上面的声卡。小孩说,没audio,那怎么成?

该声卡是Creative Labs的,驱动认出是Multimedia Audio Controller,但Windows 7安装不了驱动。用了Dell原来带来的驱动软件,即使设置了以XP兼容模式运行,也无法安装。在网上查了无数的文章和贴子,试验了很多法子,都没用。被折磨了N个小时后,决定放弃,从一个很老的闲置机器上拔了声卡出来,看是否可用,哈,Window 7居然认出来,安装了适当的驱动程序!

安装的版本是6801,好像是比较早的版本,感觉比较慢。每次使用Windows Explorer访问局域网上的共享文件,如果连不上,Windows Explorer就会死在那里,用Task Manager也杀不死,log off也死在那里,最后只能关机。

从网上的消息看,好像有人已经拿到比较新的版本,反映不错。微软好像在明年一月会开放beta测试,非常期待。

posted on 2008-12-24 13:47:52 by saucer  评论(1) 阅读(6568)

 
2008年12月18日

微软模式和实践开发团队发布了《应用架构指引》(第二版)的最终版:

Application Architecture Guide 2.0
http://www.codeplex.com/AppArchGuide/Release/ProjectReleases.aspx?ReleaseId=20586

比原计划早了几乎一个月,看来我得加把劲了。

posted on 2008-12-18 07:51:45 by saucer  评论(0) 阅读(5250)

 
2008年11月27日

微软模式和实践开发团队发布了《应用架构指引》(第二版)的最终版:

Application Architecture Guide 2.0
http://www.codeplex.com/AppArchGuide/Release/ProjectReleases.aspx?ReleaseId=20586

比原计划早了几乎一个月,看来我得加把劲了。

posted on 2008-11-27 18:04:10 by saucer  评论(0) 阅读(7112)

 
2008年11月07日

在最近的PDC大会上,微软推出了与Oslo相关的重大技术。Oslo到底是什么?根据Oslo的FAQ

“Oslo是微软的模型驱动开发平台的代号名,Oslo的目标是,通过把模型驱动应用变成主流,提供十倍以上的生产力增益。这个平台的核心是特定领域(domain-specific )的模型,语言和工具:

•       一个名为M的语言,用文字的形式编写领域模型

•       一个名为Quadrant的工具,用图形的方式编写领域模型

•       一个用于管理领域模型的Repository

•       一个带有预制领域模型和语言的库

在一起,这些构件将使得一个团队能更有效地开发、实现和维护应用和服务。”

 

这里是一些相关的资源链接:

  • Oslo 开发者中心
    http://msdn.microsoft.com/en-us/oslo/default.aspx
  • Oslo SDK October 2008 CTP 下载地址
    http://code.msdn.microsoft.com/oslo/Release/ProjectReleases.aspx?ReleaseId=1707
  • PDC上与Oslo相关的讲座录像

    1. A Lap around "Oslo" (对Oslo相关技术的综合介绍)
      http://channel9.msdn.com/pdc2008/TL23/
    2. "Oslo": The Language (对M语言的介绍)
      http://channel9.msdn.com/pdc2008/TL27/
    3. "Oslo": Building Textual DSLs (对如何建造文字形式的DSL的介绍)
      http://channel9.msdn.com/pdc2008/TL31/
    4. "Oslo": Customizing and Extending the Visual Design Experience (对Quadrant工具的介绍)
      http://channel9.msdn.com/pdc2008/TL18/
    5. "Oslo": Repository and Models (对存储中心的介绍)
      http://channel9.msdn.com/pdc2008/TL28/
  • David Chappell的《Workflows, Services, and Models - A First Look at WF 4.0, “Dublin”, and “Oslo”》
    http://msdn.microsoft.com/en-us/library/dd200919.aspx

    对其中的一段的草译,“Oslo的主要目的是使模型成为跨越应用开发周期(创建、部署和管理)的一个基本部分。在Oslo中,模型是某种东西的抽象表现,譬如一个业务过程,一个应用,或一个工作流程(别把这里的“模型”的概念与其他场景(譬如UML)中的同名术语相混淆,两者并不等同)。不是把模型的概念局限于只在设计过程中使用的描述性图表,Oslo允许模型成为应用本身的一部分。例如,一个WF工作流程可以使用Quadrant来创建,并储存于repository之中。这个工作流程是个模型,该模型存在于repository之中,但它同时也是工作流程的实际逻辑。改变模型意味着改变工作流程本身,这意味着模型和这部分的应用逻辑总是同步的。Oslo repository不仅仅可以保存应用的模型,当然,一个应用的其他部分还可以居于repository之外。然而,把模型从只是描述一个应用变成实际应用本身的观念,对于Oslo来说,是至关重要的。”

posted on 2008-11-07 14:40:53 by saucer  评论(0) 阅读(5166)

 
2008年11月06日

在PDC上的一个讲座中,微软研究所展示了一个工具,叫Pex (Program EXploration - 程序探索):

Research: Contract Checking and Automated Test Generation with Pex
http://channel9.msdn.com/pdc2008/TL51/

 

Pex项目地址:
http://msdn.microsoft.com/en-us/devlabs/cc950525.aspx

(上面链接里的下载好像是针对VS 2010的,其他的版本可在这个地址http://research.microsoft.com/Pex/downloads.aspx下载)

 

Pex是个白盒测试生成工具,可以用于帮助理解.NET代码的行为,调试问题,以及,完全自动地,创建涵盖所有边界案例的全套测试。它提供了与VS的集成。

在安装之后,如果在自己的代码中点击右鼠标,然后在上下文菜单中选择运行Pex探索(“Run Pex Explorations”)的话,它会用不同的输入运行你的代码很多次。这些输入不是任意的,也不是所有可能输入的全部组合,而是根据你的代码,分析出其中的边界条件,选出有代表性的输入。简单地说,Pex会分析每一句代码,会琢磨出达到该语句的测试输入。如果代码中有条件性分支,Pex会做案例分析,即Pex会根据代码中条件分支的数目和可能组合生成对应的测试输入。

Pex是在一个反馈循环中运作的: Pex运行代码多次,通过监测控制和数据分流,了解程序的行为。每次运行之后,Pex会挑一个早先没有覆盖的分支,建造一个描述如何达到那个分支的约束系统,然后使用约束解算器(constraint solver,这个版本用了一个叫Z3的约束解算器)决定满足对应约束的新测试输入。然后用新的输入再次运行测试。。。这个过程会重复多次。每次运行,Pex也许会发现新的代码,深入代码实现之中。通过这个方式,Pex可以探索代码的行为。

在VS中,在运行Pex探索之后,在探索结果中选择某个输入,然后选择保存测试案例的话,Pex会为你的代码生成一个测试项目,在其中生成测试类以及相关测试方法。当然你也可以选择所有的输入场景,然后保存所有的测试案例,供你做regression测试之用。

Pex在探索代码、生成测试输入时也会跟踪代码覆盖率。但Pex只有局部的覆盖率知识(Pex称之为动态覆盖率),只有VS代码覆盖率收集器才能给你提供全局的覆盖率信息。

在Pex的新手起步网页上有个简短的代码挖掘教程http://research.microsoft.com/pex/articles/pexcodediggertutorial.pdf 

 

新手起步网页上,还有更深入的教程,原理概述,参考手册和例程等等。

posted on 2008-11-06 14:39:47 by saucer  评论(0) 阅读(4603)

 
2008年10月31日

了解动态语言Ruby的,大概都知道Ruby中有一个很有意思的实例方法叫method_missing。如果在代码中调用一个某个类中不存在的方法,就会调用这个方法。Ruby on Rails中的ActiveRecord利用这个方法,可以提供很方便的动态查询方法,譬如

find_by_name
find_by_username_and_password
find_all_by_first_name_and_last_name
....

细节请参考 http://www.gargoylesoftware.com/RailsDynamicFinders.pdf

当然,通过这个方法,你还可以做许多涉及metaprogramming的东西。

 

最近发布的C# 4.0 CTP版本引进了大量的动态语言的构造,我们终于也可以很方便地实现动态方法了,

using System;
using System.Collections.Generic;
using System.Linq;
using System.Linq.Expressions;
using System.Text;
using System.Scripting.Actions;

namespace ConsoleApplication1
{
    class Data
    {
        public int ID { get; set; }
        public string Name { get; set; }
        public string Value { get;set;}
    }

       //这里使用了CTP版本中IDynamic Object Example例程中的IDOHelper项目中的Dynamic类以减少代码量
    class MyClass : System.Scripting.Actions.Dynamic
    {
        List<Data> data;
        public MyClass()
        {
            data = new List<Data>{ new Data {ID=1,Name="abc",Value="hello world" },
                new Data {ID=2,Name="def",Value="hello joycode"},
            };
        }

        public string Find(int id)
        {
            if (id <= 0 || id > 2)
                throw new ArgumentException("cannot handle this parameter:" + id.ToString());

            return Find(d => d.ID == id);
        }

        public override object Call(CallAction action, params object[] args)
        {
            if (action.Name == "Find" || action.Name == "FindByID")
                return Find((int)args[0]);
            else if (action.Name == "FindByName")
                return Find(d => d.Name == (string)args[0]);

            //当然,在这里,你可以发挥想象力,实现任何你能想到的方法

             throw new NotSupportedException();
        }

         private string Find(Predicate<Data> p)
        {
            Data d = data.Find(p);
            if (d == null)
                return String.Empty;
            return d.Value;
        }
    }

}

在客户端代码里,你可以这样

dynamic m = new MyClass();


Console.WriteLine(m.Find(1)); //Find方法在类中有声明,但其实还是通过Call方法来调用的

Console.WriteLine(m.FindByID(2));  //但FindByID则没有声明

Console.WriteLine(m.FindByName("def")); //FindByName也没有声明

这里把m声明为dynamic是关键,否则会出错。输出为

hello world
hello joycode
hello joycode

 

微软的Chris Burrows对此有更深入的讨论:

C# "dynamic," Part II
http://blogs.msdn.com/cburrows/archive/2008/10/28/c-dynamic-part-ii.aspx

posted on 2008-10-31 17:19:55 by saucer  评论(2) 阅读(4359)

 

一些讲座的录像已经上线:

http://channel9.msdn.com/tags/pdc2008/

 

哎,想看的太多了,可是每个都是一个多小时。。。。

对C# 4.0感兴趣的,一定要看一下的Anders Hejlsberg的

The Future of C#
http://channel9.msdn.com/pdc2008/TL16/

posted on 2008-10-31 00:01:25 by saucer  评论(0) 阅读(4410)

 
2008年10月29日

微软模式和实践团队已经推出了《应用架构指引》(第二版)的beta 1版本

patterns & practices Application Architecture Guide - v2.0 (Beta 1 Release)
http://www.codeplex.com/AppArchGuide

PDF版本可在此下载

http://www.codeplex.com/AppArchGuide/Release/ProjectReleases.aspx?ReleaseId=18834

 

在知道微软即将推出《应用架构指引》的第二版时,我即有意将该书翻译成中文。博文视点在了解情况后,很快与微软出版社取得联系,得到了该书的版权。在明知微软将免费提供该书英文版的情形下依然愿意出版该书,这样的胸襟非常难得,在此特向博文视点表示敬意。我计划从beta 1翻译起,希望在正式版(大概在1月中旬左右)推出不久,就能完成该书的翻译。

自四月份起,连续做了N个项目,忙得不行,到现在,虽然还有不少收尾工作,但终于有些空余时间了。适逢微软推出了无数新技术,其热闹程度,感觉象是到了春天一样,可玩的东西真是太多了,Silverlight 2, Visual Studio 2010, .NET 4, Windows 7, Windows Azure,  Windows Office Live, Oslo 和 M 语言,...Happy days are here again!

posted on 2008-10-29 05:44:02 by saucer  评论(1) 阅读(3354)

 
2008年10月28日

微软刚发布了Visual Studio 2010 和 .NET Framework 4.0 CTP版

Microsoft Pre-release Software Visual Studio 2010 and .NET Framework 4.0 Community Technology Preview (CTP)
http://www.microsoft.com/downloads/details.aspx?FamilyID=922b4655-93d0-4476-bda4-94cf5f8d4814&DisplayLang=en

目前只提供英文版的VPC映像,系统要求很高,譬如最少75G的硬盘空间,最少2G的RAM。

posted on 2008-10-28 01:51:23 by saucer  评论(0) 阅读(3497)

 
2008年09月28日

九月初,微软在CodePlex推出了
Managed Extensibility Framework
http://www.codeplex.com/MEF

托管扩展性框架是什么?

“托管扩展性框架(Managed Extensibility Framework,简称MEF),是.NET的一个新的类库,旨在促成应用和组件更大的重用。通过使用MEF,.NET应用将能从是静态编译的而变成可动态组合的。如果你正在建造可扩展的应用,可扩展的框架和应用扩展,那么MEF就可为你所用。”

今年早些时候,微软成立了一个应用框架核心开发团队(Application Framework Core team),其宗旨是在应用框架空间(WinForms, ASP.NET, WPF, Silverlight)起和基础类库(BCL)开发团队在平台底层方面一样的作用。

基础类库开发团队在负责平台底层层次上减少重复和提供共同的抽象诸多方面起了很大的作用,但在高层次方面微软还没有类似团队负责处理同类问题。于是乎,造成了一些不幸的重复(譬如每个应用模型都有若干个数据绑定模型,WPF和WF有着不同的依赖属性系统),且在应用模型代码方面缺乏共同的抽象。

于是应用框架核心开发团队就应运而生了。

这个团队的第一个具体项目就是“托管扩展性框架(MEF)”,他们发现,在.NET框架本身以及日趋托管的应用(象Visual Studio)中越来越多的地方,需要提供或者已经提供了钩子(hook),可为第三方扩展所用。譬如使用TraceSource API的TraceListener插件,Visual Studio代码分析的可插拔规则等等。

但在不存在一个内置的扩展性框架的情形下,如果开发人员想要提供这样的扩展,只好通过提供定制的机制来实现,于是造成重复劳动。他们希望MEF可以中止这样的重复,在框架和应用中鼓励以及促成建立在MEF之上的更多的扩展性。

六月初,他们推出了第一个CTP版本,九月份的这个版本是第二个版本。该版本包括完整的框架代码,还有三个例程(类似Outlook客户端的MEFlook,类似Tetris,形状可通过插件形式扩展的游戏MEFTris,以及可扩展的文件管理器)。

MEF与IoC容器的区别

从表面上,MEF有点类似IoC容器,但MEF并不是IoC容器。在这一点上,很多人都很困惑。

Oren Eini在他的博客中指出,MEF实际上是个组合框架(composition framework),而且定位客户是“大的应用”,两者合一,即可理解MEF的本质。

组合框架和IoC容器在表面上看很相似,都是以自动化的方式管理应用的依赖性,但其区别则在于细节上。IoC容器很久以前就不仅仅是管理依赖性了,它们还负责对象的生命周期,对象代理,面向aspect,事件聚合,事务管理等等东西。但组合框架则着重于单一个目的:依赖管理。听上去组合框架好像所做极有限,但其实不是这样。光从依赖管理来说,IoC容器往往是静态的,不透明的,而MEF则使得依赖管理变成一个动态的,透明的过程。

MEF的第二个方面,其定位是“大的应用”,极其大的应用,其中第一个客户大概就是Visual Studio本身。MEF提供的这些功能,
-不用装载程序集即可查询元数据
-可以静态地核实所有组件的依赖图和拒绝那些会造成系统处于不合法状态的组件
-契约适配器
-提供一套发现机制,用于定位和装载扩展
-允许附件元数据的标记设置,用于辅助查询和过滤

都是围绕着依赖管理这个主题的,但也大概来自Visual Studio是第一个客户的需求。因为Visual Studio涉及的组件成千上万,需要这样的东西,MEF是设计来处理这样的场景的。

Sidar Ok用了一个具体的例子来说明MEF并不是IoC容器,参考
What is this Managed Extensibility Framework thing all about ?
http://www.sidarok.com/web/blog/content/2008/09/26/what-is-this-managed-extensibility-framework-thing-all-about.html

另一件需要指出的事情是,MEF将是.Net 4.0的一部分,所以MEF将为.NET框架本身所用。

【参考】
1. Oren Eini的《The Managed Extensibility Framework》
http://ayende.com/Blog/archive/2008/09/25/the-managed-extensibility-framework.aspx

2. Glenn Block的《What is the Managed Extensibility Framework?》
http://codebetter.com/blogs/glenn.block/archive/2008/09/25/what-is-the-managed-extensibility-framework.aspx

3. Krzysztof Cwalina的《Managed Extensibility Framework》
http://blogs.msdn.com/kcwalina/archive/2008/04/25/MEF.aspx

posted on 2008-09-28 07:24:04 by saucer  评论(0) 阅读(4306)

 
2008年09月15日

想来很多.NET开发人员大概都读过《应用体系结构:设计应用和服务Building Distributed Applications -- Application Architecture for .NET: Designing Applications and Services)》。自2002年以来,该文一直是开发N层.NET应用的必读经典。六年过去了,.NET版本都发展到了3.5,微软模式和实践团队终于要更新《应用架构指引》了。

 

J.D. Meier,该指引的初稿已经在CodePlex上推出

patterns & practices: App Arch Guide project
http://www.codeplex.com/AppArch

在大的方面,该指引将涵盖

  • 应用类型
  • 架构风格
  • 模式
  • 逻辑层,物理层以及组件
  • 架构级热点(Hot Spots)
  • 表现层
  • 业务层
  • 数据访问层
  • 服务层
  • 服务设计
  • 质量属性
  • 趋向
  • 安全工程
  • 性能工程
  • 基线架构(Baseline Architectures)
  • 部署模式

小的方面则会讨论

  • 选择表现层技术
  • 选择数据访问技术
  • 选择工作流技术
  • 比较inline QL和存储过程
  • 比较MVC模式和 MVP模式
  • 比较领域模型驱动和结构驱动设计

 

其组织框架(App Arch Meta Frame)可参考下图

场景(Scenarios)提供了评估架构的背景和上下文, 质量属性(Quality Attributes)是指种种非功能性需求(可靠性,安全要求,性能,灵活性,可维护性等等),需求和约束(Requirements / Constraints )是指种种影响架构的用户,业务以及技术上的规则。

应用类型包括web应用,富客户端,移动式等等。架构风格则包括N层,客户-服务器,SOA等等。架构帧(Architecture Frame)则包括了种种你需要做很多决定/ 选择的架构上的热点。

他们将关键的问题领域场景分成了几个帧(Frame),包括

1. 表现层场景帧(Presentation Layer Scenarios Frame) ,其中的热点包括

  • 缓存
  • 组合(Composition)
  • 异常管理
  • 输入
  • 布局
  • 导航
  • 表现层实体
  • UI 组件
  • UI 过程组件
  • 验证

2. 业务层场景帧(Business Layer Scenarios Frame),其中的热点包括

  • 认证
  • 授权
  • 业务组件
  • 业务实体
  • 缓存
  • 并发性和事务
  • 数据访问
  • 异常管理
  • 日志记录
  • 服务接口
  • 验证
  • 工作流

3. 数据访问层场景帧(Data Access Layer Scenarios Frame),其中的热点包括

  • 概论
  • BLOB
  • 批处理
  • 连接
  • 数据格式
  • 异常管理
  • 安全考虑
  • 存储过程
  • SQL 命令
  • 验证
  • XML

4. 服务层场景帧(Services Layer Scenarios Frame),其中的热点包括

  • 概论
  • 认证
  • 授权
  • 通讯
  • 异常管理
  • 消息通道
  • 消息之构建
  • 消息端点(Endpoint)
  • 消息保护
  • 消息路由
  • 消息转换
  • 消息交换模式Message Exchange Patterns
  • REST
  • SOAP
  • 验证

J.D. Meier的博客上还有很多相关讨论,推荐订阅

J.D. Meier's Blog
http://blogs.msdn.com/jmeier/default.aspx

posted on 2008-09-15 10:22:26 by saucer  评论(0) 阅读(5572)

 
2008年09月01日

今天从Oren Eini的博客上看到一个很幽默的录像,说实话,都有点心酸的感觉,估计几乎每个开发人员都会有同样的感觉

http://blip.tv/scripts/flash/showplayer.swf?file=http://blip.tv/rss/flash/1067270

请各位老板,开发主管,项目经理,今天一定要去拥抱一下你的开发人员!

 [附其中一些文字的粗浅翻译]

Developers everywhere are in terrible pain.
不论何地,开发人员都是痛苦无比。

I am in pain.
我很痛苦。

We're 4 months into a 5 month schedule and I just received the final requirements yesterday (and they've changed again!)
5个月的日程,开发已经进行了4个月,我昨天才收到最后的需求,而今天,这些最后的需求又变了!

I spend half my days in meetings about how to get more work done (instead of working)
我一半的时间都陷于讨论如何完成更多的工作的会议中,而不是做工作

My boss read in a magazine that developers using "_____" programming language are twice as productive. So he bought us a copy and cut our schedule in half.
我们老板在一本杂志上读到使用某种编程语言的开发人员的效率高2倍之多,所以他给我们买了该语言,然后将我们的日程切掉一半

Every day my boss changes his mind about what we're building
对我们该开发什么,我们老板的主意每天一变

(父亲)People keep asking me to fix their e-mail, so I have no time to code
大家不停地叫我修补他们的电邮,所以我根本没时间编程

(儿子)My daddy has no more time for me
我爸都没时间陪我

Some consultants told my boss they could build our next version in half the time, for half the money. He believed them, but now they've spent all their budget, used all their time and ...are still only half finished. Now they're gone and their code is a disaster. We have to fix it and finish what they started
某些咨询师告诉我老板,他们只要一半的时间,一半的经费就可开发我们下一个版本。他信了他们,但现在,他们花完了预算,用光了时间,还只完成了一半。现在,他们走了,而且他们的代码糟糕无比,我们没有办法,只能来完成他们尚未开发完的东西

Hug a developer today.
今天,请去拥抱个开发人员

(小孩)I just finished an intensive 6 week visual basic course
我刚完成一个6星期的visual basic速成班

posted on 2008-09-01 08:53:55 by saucer  评论(1) 阅读(5755)

 
【第1页/共28页,409条】
首页
前页
1
...

Powered by: Joycode.MVC引擎 0.5.1.0