pojia

  博客园 :: 首页 :: 新随笔 :: 联系 :: 订阅 订阅 :: 管理 ::
  30 随笔 :: 0 文章 :: 5 评论 :: 0 引用

2008年12月19日 #

什么是导出属性?即 计算出来的属性;

比如:SaleItem.TotalCost = Item单价×Item数量 , 那么TotalCost就是SaleItem的导出属性;

现在我们有了SaleItem领域模型;

那么如何设计数据库比较合适?

   对应有个t_SaleItem,  Column 是否需要TotalCost? 如果我们不要,那么程序要获取TotalCost的数据时候,就是通过计算得到;如果需要,那么在产生这个Sale Event 的是计算出结果并放到TotalCost字段上。

  因此就这个例子而言,它是需要在数据表中加这个字段的,原因是如果可以允许延迟付款,那么在为付款期间,调整了商品的零售价,TotalCost也会变化,这种情况对购买商品的客户来说是不可接受的;

  那什么时候不需要这个Column,在这样的情况下,某人要知道自己年龄

         

  在这个模型的UserEntity.Age = CuttentDate - UserEntity.Birthday; 对于这样情况,我们在创建t_User的时候就可以不需要Age这个Column;

posted @ 2008-12-19 16:32 破甲 阅读(65) 评论(0) 编辑

2008年4月5日 #

什么是动态横切,静态横切?动态和静态的区别在哪?

 首先,横切是面向方面编程的专用名词;大概是指在对象中插入新的职责;就好像一面包,我们把它从中间切开,放入点肉类,就成了汉堡,吃起来味道就不一样了;
横切有两种,动态横切与静态横切;经常我们用到动态横切就是指方法拦截,而静态就是MIXIN;
动态横切是通过切入点(pointcut)和链接点(joint point)在一个方面(aspect)中的创建行为的过程;方面(aspect)定义了所有的链接点,切入点以及通知(advice),以便把需要切入的职责(interweave)注入到原来的对象中;
(名词解释:链接点(joint point)指需要我们要注入职责的地方;切入点(pointcut)确定具体植入位置,在职责前植入还是在后植入;通知(advice)也就拦截器了,就是你需要现在这些职责的代码;)

静态横切是通过在不修改原有职责的基础上增加新的职责;以往我们用过类的继承来实现,但继承是种强依赖关系,怎么让他们松藕,这个时候我们用静态横切,用mixin;
比如:
 class zoo {
    //职责
    public string 发声(){.....}
}
class bird : zoo {
   pubic string 飞行 (){.......}
}
class newbird{
  pubic string 飞行 (){.......}
}
如果我们使用minix,,在定义bird的时候 ,我们就不需要继承zoo了 。。我们只需要增加配置:
aspect newbirdAspect for newbird
    include zoo
end

那么我们在运行时候就有:
AspectLanguageEngineBuilder b = new AspectLanguageEngineBuilder (配置文件);
AspectEngine aEngine = b.build();
newbird obj = aEngine .WrapClass(typeof(newbird )) as newbird ;
obj .飞行();  //这里就是MIXIN的功劳了
obj .发声();
posted @ 2008-04-05 18:44 破甲 阅读(190) 评论(0) 编辑

2008年4月2日 #

链接:http://www.agiledon.com/post/2008/03/Indians-Soal-Retrospectives.aspx

哈哈!!在这里加个链接,看老张的BLOG
posted @ 2008-04-02 11:20 破甲 阅读(39) 评论(0) 编辑

2008年4月1日 #

链接:http://www.dotnettools.org/Blog/article.asp?id=211


  • LINQ to SQL 目前只支持SQL Server(SQL Server Compact版本正在开发中),有迹象表明,也可能会支持DB2,Informix IDS,Oracle官方说法是他们在关注Linq的进展,VistaDB, MySQL。。。但可以预见的是Linq如果要在2007年底RTM,那么要支持其它数据库的时间上,并不多,甚至我在Weblog上看到说,对SQL Server Compact的支持都不包含在LINQ v1版本计划中。不过,MS,IBM,Oracle他们如果真决心做,那么时间不是问题上面的结论如果成立,那么我的第一观点是,LINQ to SQL不能算纯粹意义上的ORM,因为它支持的数据库种类和类型还不够多
  • 从技术的先进性和难度来看,Java Persistence API和Linq是解决不同层面问题的两种技术,并且从开发人员的角度来看,Java Persistence API没有Touch到Linq关注的层面,上面我说了,从编程语言的角度来看,LINQ是来自最底层编译器和开发语言的支持,Java Persistence没这么底层;另外对于Java Persistence API,Adopt已有的ORM技术比如Hibernate, TopLink, JDO方面,Java Persistence API更像已有Java ORM的集大成者新建的一个API,而LINQ to SQL,LINQ to DataSet,LINQ to XML,LINQ to Entities,LINQ to Object,LINQ to Flickr, LINQ to NHibernate, LINQ to LDAP 已经都是板上定钉的事情,所以从设计上来看,LINQ更大气和宏观,因为一旦从编译器和开发语言的层面的支持,那么其融合渗透和应用的程度就相当高的,我认为其"亲和力"相当强悍
  • ADO.NET Entity Framework(ADO EF)更多的是一个实体或概念设计的服务框架,是现实的实体和实体间的关系映射到将对象层,CLR 类和它们之间的关系上,甚至ADO.NET Team也避免让ADO EF概念上变成一个类似ORM的设计工具,ADO EF强调的三层{概念层/实体层(Conceptual layer), 元数据层(Source schema)和影射层(Mapping layer)}的灵活、独立和松散耦合,从而使得你可以将一个概念层/实体层通过定义多个影射层从而映射到多个不同的数据库上,而这一点LINQ to SQL做不到,首先LINQ to SQL不支持实体的多重继承(支持有限的继承),甚至有评论说LINQ to SQL RTM之前都不会获得many-many relationships的支持,LINQ to SQL更多的是使用dbml属性非常紧耦合地绑定到一张表的某些特定的数据库字段上。也就是说LINQ to SQL没有这么多层,另外它强调的是编程语言对数据查询和分析的结构化支持(从编程语言的层面)
  • 理论上ADO EF是一个浩大大工程的框架,从而能够更好的支持流行的Domain Model Driven的开发,这要求它要有三层的设计工具展现你的设计,突现和定位你的实体关系,要求工具能够根据实体层产生数据库的脚本或是反向工程,同时需要有精度极高同时有非常Smart的代码生成工具和界面,同时,而目前Orcas Beta1单薄的的EDM Wizard根本不足以完成这些要求,更早先发布的Entity Data Model Designer Prototype已经成为丰碑快不可超越,看看这里有比较漂亮的一个设计器的录像--很酷
  • “Entity Framework the March CTP and Beta 1 are almost identical. There's some last bit of features that we're busily working on now that will appear in Beta 2 and the Orcas Release”这意味着Orcas Beta1和March CTP中 ADO EF变化并不大(ccBoy建议:在Orcas Beta1你可以精力重点放在 LINQ to SQL上),甚至有人认为Orcas's Entity Framework 进度的重大的标志在于Orcas能够提供出优良的EDM Designer,满足我们上面说的工程需求,所以Orcas Beta2将是ADO EF的一个重大里程碑,所以结论是,ADO EF和 LINQ to SQL侧重点上看两者的关注点非常不同,相比来说ADO EF开发或性能上会奔重些,但是ADO EF倾向Domain Model Driven和支持更多的流行的数据库或数据源,但ADO EF绝对不是一个简单的ORM Tools,理解成实体框架和对象服务层技术会更宏观,这里面LINQ成为ADO EF中很小的一个低层支撑技术,我刚刚说了LINQ的亲和力
  • 从技术开发的角度来看,如果你的实体/业务模型(或者称为问题域)和已有的数据模型不匹配的时候,你需要考虑ADO EF,反正如果你的实体/业务模型(或者称为问题域)和已有的数据模型匹配,那么LINQ to SQL 会是不错的选择至于LINQ to Entities和LINQ to SQL,上文已经说的比较清楚(思归翻译的版本),我总结一下,相同点是,LINQ to Entities是LINQ to SQL的一个超集或加强版(Superset),你看到两者的Feature对比上,LINQ to Entities更重,它运行或说让你在一个概念数据模型上(Conceptual data model),你对对象的查询是发生在这一层
  • 那么不同的地方在于,你使用LINQ to SQL的时候,你的映射,产生的CLR/.NET类是和你的数据/数据库模型紧耦合或绑定的,如果你改变对象模型,那么你要直接修改这些类,同样如果数据模型改变,你要使用重新生成对象代码,而ADO EF在数据/数据库模型上建立一个概念层/实体层,这使得你要先定义概念层/实体层,接着建立数据/数据库的脚本(描述),然后在一个影射层建立你的实体和数据之间的逻辑映射,这使得业务和数据源之间有了很好的藕合度和隔离。而LINQ to SQL无法达到这样的效果,另外LINQ to Entities也直接带有了ADO EF提供的另外一些强项,比如实体的继承(Entity Inheritance ),实体的组合(Entity Composition)
  • Entity SQL (eSQL)更多的时候,它是SQL语句的变体是完全面向查询语言的(Query Language),但是是对应的是对实体数据模型的查询,是对实体,实体中的属性进行查询,更多的时候Entity SQL 是面对ADO EF的Object Services,对象服务是ADO EF中能够将实体像对象一样工作和操作的服务,事实上Object Services往往是事实上的内存对象数据库,当然在这里你只能查询对象或实体并获得它们,你不能是使用SQL DML语句一样,Update或Deleted对象或实体(当然未来可以,现在v1版本是做好查询),当我们要和上面说的概念层/实体层交互的时候,第一你可以使用Entity SQL (eSQL),第二你要使用LINQ to Entities,Entity SQL (eSQL)是文本和字符的,所以它支持组合(composable),比如子查询,而后你明白所有的LINQ to XXXX,其实就是说你如何让你在编程语言这个层面,很快地享受到LINQ针对XXXX(数据源或对象源)的数据集成和查询的能力以及便利(内置的表达式,操作语句,代码生产效率,性能等等)
  • 最后是Entity Client,这个一个新型的API,也就是专门用来访问实体源或实体数据模型,Entity Client使用自己的语言-Entity SQL (eSQL),它也是ADO.NET提供的另外一个数据源提供驱动,你可以用理解SqlClient一样来理解Entity Client,它是另外一条访问实体数据模型的途径,它存在的意义有两个,第一它的访问性能会高,第二,EntityClient返回的结果是dbDataReader,这意味着你可以使用统一或者你非常熟悉的代码经验比如你使用ADO.NET操作 SQL Server, Oracle,MySQL的技能对查询回来的数据进行娴熟地处理,抑或是如拌凉菜般地翻腾这些数据:)
作为一个顾问和实践者,我们首先要去做,然后要面临给予自己和其他的人一些建议,在未来的6个月到一年:
  • 1. LINQ的出现展示了一种最底层的新型张力,任何现代编程语言最重要的能量和动力在这个语言的编译器,LINQ的出现让所有有关语言先进性争论的时代划句号,作为技术人员你需要察觉到这种变化和带来的影响
  • 2. 从目前的Orcas Beta1版本来看,建议你在未来的6-12月优先学习C# 3.0和LINQ,掌握新型的表达式、语法和语句,这是未来编程语言中和For,IF语句一样的基本功,而每个开发人员需要熟练的使用这些语句,当然能够研究和搞明白这些新语句的背后的实现和原理,那是最佳的
  • 3.对于那些已经掌握C#3.0和LINQ的中级的开发人员来说,在LINQ to SQL(LINQ2SQL)和ADO.NET Entity Framework来说,可以优先考虑学习和研究LINQ to SQL,并将其这种技术在项目或应用中做以实践
  • 4.ADO.NET Entity Frameworkd的 Entity Desiger出来之前,保持对它的关注,而不用花太多的时间,另外从一个开发人员的角度来看,ADO EF不是必须的,甚至在设计人员特别是Domain Model Drivening的人员要关注和准备的,当然这些在6个月之后考虑和研究都不晚
  • 5.Visual Studio Orcas的发布日期依然是一个很关键的因素,可以预见的是C# 3.0和LINQ将会在人们期望和愿望实现的时间点发布,但涉及到ADO.NET Entity Framework的部分有多少,这个要观察和注意,但反过来说,有了LINQ和LINQ to SQL已经让我们感到物有所值了
  • 6.在你的项目中考虑新的功能特性对应用架构的影响,同时也尽可能多练习在ASP.NET这种传统的开发技术下LINQ和C# 的应用
  • 7.继续保持对Visual Studio Orcas的关注,因为.NET 3.5或.NET 4.0已经开始走向更成熟,先进和自信的一面
posted @ 2008-04-01 15:49 破甲 阅读(480) 评论(0) 编辑

两种的特性:

Feature

LINQ to SQL

LINQ to Entities

Language Extensions Support

Y

Y

Language Integrated Database Queries

Y

Y

Many-to-Many (3way Join/Payload relationship)

N

N

Many-to-Many (No payload)

N

Y

Stored Procedures

Y

N (to be added)

Entity Inheritance

N

Y

Single Entity From Multiple Tables

N

Y

Identity Management / CRUD features

Y

Y


Kevin Hoffman的结论是,

  1. 如果你需要有对底层数据库数据定义的隔离,使你的对象更有弹性,那么采用实体框架
  2. 如果你需要实体继承和实体组合,那么使用实体框架
  3. 如果你已经有大量DLINQ编码,不用实体也运行正常,那么别浪费时间重构到实体框架
  4. 如果你需要针对对象模型做LINQ查询,但你的对象模型与数据库里的数据表有1:1对应的话,你大概不需要实体框架
  5. ADO.NET vNext包含一个“客户端视图(client-views)”引擎,假以时日,其威力之强劲,让人难以拒绝实体框架

Paul Gielens也指出,选择哪个技术,很大程度上取决于你的数据库定义与你的domain model是否相近。如果非常相似,那么使用LINQ to SQL更直接了当,否则就使用ADO.NET实体框架。

(题外话:其实在怎么选择上,应该在Linq 出来之前我们就已经有答案了,做什么选择取决于项目的具体需要,我们是否需要有PO,BO,VO这样的东东只与设计有关,跟使用什么技术无关)

下面有一个牛人级人物的链接:http://blog.joycode.com/saucer/archive/2008/02/09/114500.aspx

(题外话:好像现在linq to sql 只是针对sql server的,如果要考虑其他数据库,可选择linq to HQL或者linq to NH)

posted @ 2008-04-01 14:50 破甲 阅读(2307) 评论(1) 编辑

linq to sql 算ORM吗?
    看了很多资料,总结的结果,它不是,比较它和NHibernate:
  
  • 在DLINQ(linq to sql)中,虽然可以在语言层级定义查询逻辑。但是依然没有将数据库持久化数据映射为领域对象,所以还是一种针对数据库的编程模型。而NH则可以直接将关系数据映射为领域模型,这是DLINQ的主要问题。
  • DLINQ不支持继承类的映射。
  • NH已经提供了许多帮助进行领域面向对象建模的特征。而DLINQ目前还无法拥有。
  • 自己认为最主要的是它没有做到持久化,而这一点微软把它交给了Ado EF来做了,貌似4.0的Enterprise也提供了一个Unit这样一个轻量级的东东;可见微软在EDM/ORM上也追上来了;

       http://blog.csdn.net/edisundong/archive/2007/09/01/1768779.aspx

    posted @ 2008-04-01 14:28 破甲 阅读(495) 评论(0) 编辑

    2008年3月27日 #

    匿名方法实现

    编译器为匿名方法生成的代码很大程度上依赖于匿名方法使用的参数或变量的类型。例如,匿名方法使用其包含方法的局部变量(也叫做外部变量)还是使用类成员变量和方法参数?无论是哪一种情况,编译器都会生成不同的 MSIL。如果匿名方法不使用外部变量(也就是说,它只使用自己的参数或者类成员),则编译器会将一个私有方法添加到该类中,以便赋予方法一个唯一的名称。该方法的名称具有以下格式:

    <return type> __AnonymousMethod$<random unique number>(<params>)
    

    和其他编译器生成的成员一样,这都是会改变的,并且最有可能在最终版本发布之前改变。方法签名将成为它指派的委托的签名。

    编译器只是简单地将匿名方法定义和赋值转换成推理委托类型的标准实例,以包装机器生成的私有方法:

    SomeDelegate del = new SomeDelegate(__AnonymousMethod$00000000);
    

    非常有趣的是,机器产生的私有方法并不显示在 IntelliSense 中,也不能显式地调用它,因为其名称中的美元符号对于 C# 方法来说是一个非法标记(但它是一个有效的 MSIL 标记)。

    当匿名方法使用外部变量时,情况会更加困难。如果这样,编译器将用下面的格式添加具有唯一名称的私有嵌套类:

    __LocalsDisplayClass$<random unique number>
    

    嵌套类有一个名为 <this> 的指向包含类的引用,它是一个有效的 MSIL 成员变量名。嵌套类包含与匿名方法使用的每个外部变量对应的公共成员变量。编译器向嵌套类定义中添加一个具有唯一名称的公共方法,格式如下:

    <return type> __AnonymousMethod$<random unique number>(<params>)
    

    方法签名将成为被指派的委托的签名。编译器用代码替代匿名方法定义,此代码创建一个嵌套类的实例,并进行必要的从外部变量到该实例的成员变量的赋值。最后,编译器创建一个新的委托对象,以便包装嵌套类实例的公共方法,然后调用该委托来调用此方法。图 9 用 C# 伪代码展示了编译器为图 7 中定义的匿名方法生成的代码。

    posted @ 2008-03-27 20:14 破甲 阅读(46) 评论(0) 编辑

    简单的 Where,实现可能如下:
    public static List<T> Where (this List<T> list,委托 delegate)
    {
         List<T>  tmpList = new List<T> ();
         foreach( T p in list){
            if(delegate(p)){   
              tmpList.add(p);
             }
        }
         return tmpList;
     }

    List<Person> persons = new List<Person> {"sds","sdsd"};

    下面分别使用Lambda表达式和匿名方法
    List<Person>  tmp = persons.Where(p=>p.Name =="sds");
    等于List<Person>  tmp = persons.Where((Person p)=>p.Name =="sds"); //编译器
    还等于List<Person>  tmp = persons.Where(Delegate(Person p) {
                                                                           return p.Name =="sds";
                                                                       })

    不过linq to object采用的是延迟查询;在看下面一例:
      static void Main(string[] args)
      {
        var ints = new int[] { 1, 2, 3, 4, 5, 6 };
        IEnumerable<int>  q = from i in ints select i;

       foreach(............)
      }
      此时的q并未返回查询的结果,而是返回一个IEnumerable<int>,以使foreach可以工作;

    这里有准确的说法:http://blog.joycode.com/scottgu/archive/2007/04/09/100744.aspx
    posted @ 2008-03-27 17:46 破甲 阅读(471) 评论(0) 编辑

    2008年3月25日 #

    摘要: Oracle通过多版本的特性支持读一致性. 当select查询接触到一个被X锁的块时,Oracle绕开锁,并从回滚段中重构数据;以实现数据的一致读; 如果是其他数据库,读取器则会被X锁阻塞;直到X锁被释放阅读全文
    posted @ 2008-03-25 11:24 破甲 阅读(570) 评论(0) 编辑

    2008年3月24日 #

    摘要: 共享锁:当事务T 为一数据对象加上此锁时,在T事务中,可以对此对象读取和修改,其他事务也只能读取和在加上S锁,不能加X锁,只有等到T事务结束后,才能对此对象加X锁排他锁:当事务T为数据对象加上此锁时,在T事务中,可以对此对象读取和修改,其他事务不能读和修改,更不能加任何锁定,现在事务T对此数据对象是独占的,阅读全文
    posted @ 2008-03-24 22:10 破甲 阅读(671) 评论(0) 编辑