另有entity framework好的文章贴个地址,谢谢。在学习asp.net mvc的朋友加我qq:4111852

解决方案 »

  1.   

    db.users.Where<Answer>(u => u.id == 10 || u.id == 9)
      

  2.   

    这个反过来理解
    http://www.cnblogs.com/Abbey/archive/2011/07/17/2107917.htmlstring[] cities = { "London", "Madrid" };
    IQueryable<Customer> custs = db.Customers.Where(c => cities.Contains(c.City));我在自己的Blog里专门做了笔记,呵呵。
      

  3.   

    Contains(),包含,完全匹配,非Like
      

  4.   


    那是两个完全不同的方法,你说的这个是String.Contains...
      

  5.   

    EF中,2楼的方法应该是like这才是EF中in的实现
             public static IQueryable<TEntity> In<TEntity, TValue>(this IQueryable<TEntity> source, Expression<Func<TEntity, TValue>> valueSelector, IEnumerable<TValue> values)
             {
                 if (null == valueSelector) { throw new ArgumentNullException("valueSelector"); }
                 if (null == values) { throw new ArgumentNullException("values"); }
                 ParameterExpression p = valueSelector.Parameters.Single();
                 // p => valueSelector(p) == values[0] || valueSelector(p) == ...
                 if (!values.Any())
                 {
                     //return e => false;
                     return source;
                 }
                 var equals = values.Select(value => (Expression)Expression.Equal(valueSelector.Body, Expression.Constant(value, typeof(TValue))));
                 var body = equals.Aggregate<Expression>((accumulate, equal) => Expression.Or(accumulate, equal));
                 return source.Where(Expression.Lambda<Func<TEntity, bool>>(body, p));
             }
      

  6.   


    如果是针对这样的SQL查询:
    select * from table where city in ('London', 'New York', 'Paris')那么我想2楼中的提供的是IEnumerable<T>.Contains(),而不是String.Contains()。这里是string与string[]的匹配,不是string与string,并且是大小写敏感的。
    string[] cities = { "London", "Madrid" }; 
    IQueryable<Customer> custs = db.Customers.Where(c => cities.Contains(c.City));
      

  7.   

    哦,确实是in,但只支持字符串.而且我们需要的是int型的in,所以才有了上面的那个LINQ扩展函数.
      

  8.   

    呵呵,我也是学的一个简便的方法。这种方式只适合于in这样枚举的方式,不适合between。要int的in,把上面的string[]换成int[]应该也行的,呵呵。
      

  9.   

    我测试了一下,EF中连string[]也不行,你用的应该是linq to sql 而非entity framework,entity framework中用的是 linq to entity,跟linq to sql是有区别的
      

  10.   

    我也刚在学LINQ。书里有一章LINQ to Entities,讲的是Entity类的内部实现细节。不知道你说的LINQ to Entity是不是我这样的,说的不对的地方还请指正。我往项目里添加一个新项目:ADO.NET实体数据模型,把Northwind整个库的表、存储过程之类的映射到Entity Class上,然后使用LINQ对这些Entity类进行操作。这算LINQ to Entities了吗?如果是,那上面我说的方法,能编译,能运行,能返回正确的行。
      

  11.   

    LINQ TO SQL我没用过,不知道创建映射的时候有什么区别.
    EF会生成一个EDMX文件,LINQ TO SQL不知道有没有.
    如果你用了EF,并且是以延迟加载的方式过滤数据源,那就是linq to entity.
    比如我这里,VS会提示linq to entity不支持......而不会说linq to sql不支持.......
    我也是菜鸟来着,我只知道linq to sql 和 EF 是两种不同的框架,linq to sql 比EF出来的早.
      

  12.   

    用“ADO.NET实体数据模型”,会在项目里添加一个.edmx文件。而用“LINQ to SQL类”,生成一个.dbml文件。但是二者为支持LINQ而实现的内部细节是一致的,只有一些非常细微的差别。我也还在学习和研究。但无论是上述哪种方式生成的Entity类,在使用LINQ查询上都是一致的。
      

  13.   

    在Entity类这一层上确实没什么差别,但是在LINQ查询上却有着不小的差别,MSDN中有一张列表,就是罗列各种LINQ查询语法在EF 和 LINQ TO SQL中的支持程度和两者的区别.
      

  14.   

    哈哈,说了半天,反应过来了。我之前一直把2个混淆了。你说是ADO.NET Entity Framework吧。那个我个人理解的相当于LINQ to SQL的升级版,最近正在看这方面的书。我感觉ADO.NET Entity Framework的实现,有点类似于一个面向对象的数据库了。而LINQ to SQL只是一个简单的数据库向类的映射。