提示51. 怎样由任意形式的流中加载EF元数据
在提示45中我展示了怎样在运行时生成一个连接字符串，这相当漂亮。
其问题在于它依赖于元数据文件(.csdl .ssdl .msl)存在于本地磁盘上。
但是如果这些文件存在于web服务器中或者类似的位置，甚至你无权访本地文件系统而无法把它们拷贝到本地呢？
原来你也可以由流中加载元数据，这篇提示将告诉你怎么做。
步骤1：获得用于CSDL，MSL与SSDL的XmlTextReaders：
这可以尽可能的简单，如‘new XmlTextReader(url)’。
但是在这个例子中我准备展示给你怎样由字符串变量来完成这个操作，当然这个字符串你可以由任意地方得到：
string csdl = "…";
string ssdl = "…";
string msl = "…";
var csdlReader = new StringReader(csdl);
var ssdlReader = new StringReader(ssdl);
var mslReader = new StringReader(msl);
var csdlXmlReader = new XmlTextReader(csdlReader);
var ssdlXmlReader = new XmlTextReader(ssdlReader);
var mslXmlReader = new XmlTextReader(mslReader);
步骤2：创建元数据ItemCollections：
接下来你需要为CSDL准备一个EdmItemCollection，为SSDL准备一个StoreItemCollection以及为MSL准备一个StorageMappingItemCollection：
var edmItemCollection = new EdmItemCollection(
new[] { csdlXmlReader }
);
var storeItemCollection = new StoreItemCollection(
new[] { ssdlXmlReader }
);
var storeMappingItemCollection =
new StorageMappingItemCollection(
edmItemCollection,
storeItemCollection,
new [] { mslXmlReader }
);
远程还感兴趣的唯一对象就是StorageMappingItemCollection，与MSL一起，需要其它ItemCollection来验证映射。
步骤3：创建一个MetadataWorkspace：
接下来你需要将这些ItemCollection组合到一个MetadataWorkspace：
var mdw = new MetadataWorkspace();
mdw.RegisterItemCollection(edmItemCollection);
mdw.RegisterItemCollection(storeItemCollection);
mdw.RegisterItemCollection(storeMappingItemCollection);
步骤4：创建一个EntityConnection：
最后我们需要一个EntityConnection。要创建一个EntityConnection我们需要一个本地数据库连接 – 一般情况下这是一个SqlConnection，但是因为EF有一个提供程序模型，这个连接也可以为其它如Oracle数据库的连接字符串：
var sqlConnectionString = @"Data Source=.\SQLEXPRESS;Ini…";
var sqlConnection = new SqlConnection(sqlConnectionString);
var entityConnection = new EntityConnection(
metadataWorkspace,
sqlConnection
);
步骤5：创建ObjectContext并按需求使用
最后一步使用你刚创建的EntityConnection来构造你的ObjectContext，并像一般情况一样使用：
using (var ctx = new ProductCategoryEntities(entityConnection))
{
foreach (var product in ctx.Products)
Console.WriteLine(product.Name);
}
就是这样…不一定简单，一旦你了解怎样做了也算简单。
提示52. 怎样在数据服务客户端中重用类型
默认情况下，当你添加一个数据服务的引用后你会得到自动生成的代码，其中包含一个强类型的DataServiceContext及所有ResourceType的类。
点击“显示所有文件”可以看到项目中这个自动生成的代码：
然后展开你的数据服务的引用，再展开从属的Reference.datasvcmap，然后打开Reference.cs文件：
步骤1 – 关闭代码生成
如果你要重用一些已存在的类，你需要关闭代码生成。
这相当容易 – 选择Reference.datasvcmap文件进入它的属性，然后清空Custom Tool属性，其默认值为‘DataServiceClientGenerator’。
步骤2 – 创建一个强类型的DataServiceContext：
当我们关闭了代码生成，我们也失去了使编程更方便的强类型的DataServiceContext。
你可以像这样编写自己的DataServiceContext，代码相当容易：
public class SampleServiceCtx: DataServiceContext
{
public SampleServiceCtx(Uri serviceRoot) : base(serviceRoot) {
base.ResolveName = ResolveNameFromType;
base.ResolveType = ResolveTypeFromName;
}
protected Type ResolveTypeFromName(string typeName)
{
if (typeName.StartsWith("Sample."))
{
return this.GetType().Assembly.GetType(
typeName.Replace("Sample.", "Tip52.")
false);
}
return null;
}
protected string ResolveNameFromType(Type clientType)
{
if (clientType.Namespace.Equals("Tip52"))
{
return "Sample." + clientType.Name;
}
return null;
}
public DataServiceQuery<Product> Products {
get {
return base.CreateQuery<Product>("Products");
}
}
}
注意Product属性简单返回DataServiceQuery<Product>，其中Product是我们试图重用的类型。
使这工作的关键是由数据服务Resource typeName映射到一个客户端Type的代码，反之亦如此。
这个映射由两个函数来控制，我们在构造函数中告诉DataServiceContext这两个函数。你可以看到在这个例子中我们只是简单的由客户端的’Tip52’的命名空间到服务器端’Sample’这个命名空间。
步骤3 – 试一试：
一旦你建立了解析器，你就可以很容易的重用已存在的类型：
var root = new Uri("http://localhost/Tip52/sample.svc");
var ctx = new SampleServiceCtx(root);
foreach (Product p in ctx.Products)
{
Console.WriteLine("{0} costs {1}", p.Name, p.Price);
p.Price += 0.30M; // Cross the board price increases!
ctx.UpdateObject(p);
}
ctx.SaveChanges();
就是这样，哈。
警告：
仅当客户端与服务器两端属性名称相同时这才可以工作，因为没有方法重命名属性。
同样由于数据服务客户端中对象实体化工作的方式，当你的类有一个Reference属性及一个backing外键属性并且类进行了自动fix-up使两个值保持一致时这将不会工作。
提示53. 怎样调试EF POCO映射的问题
如果你尝试在EF4.0中使用POCO类，相对更容易在将模型映射到CLR类时遇到问题。
如果你在这里遇到任何恼人的问题，弄清楚事情的最佳的方法是尝试显式为POCO类型加载元数据。
例如，假如Product是一个POCO类型，并且你在使其工作时遇到问题，你可以尝试下这段代码来找出问题是什么：
using (MyContext ctx = new MyContext())
{
ctx.MetadataWorkspace.LoadFromAssembly(
typeof(Product).Assembly,
MappingWarning
);
}
其中MappingWarning可能是任意接受一个字符串且无返回值的方法，如这样：
public void MappingWarning(string warning)
{
Console.WriteLine(warning);
}
当你完成这步，EF将遍历你程序集中的类型，试图查看它们是否与概念模型中的类型匹配，如果某些原因一个CLR类型被识别并且随后被排除-不是一个有效的匹配-你的方法将被调用，接着在我们例子中警告会弹出到控制台。
提示54. 怎样使用声明表达式(Statement Expression)提升性能
背景：
在最近编写数据服务提供程序系列博文的过程中，我停止编写这种使用反射将属性值由一个对象拷贝到另一个的代码段：
foreach (var prop in resourceType
.Properties
.Where(p => (p.Kind & ResourcePropertyKind.Key)
!= ResourcePropertyKind.Key))
{
var clrProp = clrType
.GetProperties()
.Single(p => p.Name == prop.Name);
var defaultPropValue = clrProp
.GetGetMethod()
.Invoke(resetTemplate, new object[] { });
clrProp
.GetSetMethod()
.Invoke(resource, new object[] { defaultPropValue });
}
问题：
这段代码至少有两个主要问题。
1. 其通过反射在一个循环中查找属性与方法
2. 在一个循环中使用反射调用那些方法。
我们可以将所有属性的get/set方法存储于一些可具有缓存能力的数据结构来解决问题(1)。
但是修复问题(2)需要多一点技巧，要使这段代码真正泛型化，你需要一些如轻量级代码生成之类的东西。
解决方案：
多亏.NET4.0添加了声明表达式。这意味着现在你可以创建描述多行声明的表达式，并且那些语句可以像其他任务一样执行。
波拉特说‘好’…
在网上一番搜索，找到了Bart的这篇关于声明表达式的优秀博文，这足以让我激动万分，希望对你也是如此。
步骤1 – 熟悉API
带着发现新东西的热情，我决定先找些简单的东西尝试，尝试把这个委托对象转换为一个表达式：
Func<int> func = () => {
int n;
n=2;
return n;
};
如果你只这样做，结果很可怕：
Expression<Func<int>> expr = () => {
int n;
n = 2;
return n;
};
但不幸的是当前C#不支持这种写法，取而代之的是你需要手工构建这个表达式，像这样：
var n = Expression.Variable(typeof(int));
var expr = Expression.Lambda<Func<int>>
(
Expression.Block(
// int n;
new[] { n },
// n = 2;
Expression.Assign(
n,
Expression.Constant(2)
),
// return n;
n
)
);
相当容易哈。
步骤2 – 证明我们可以指定到一个属性
现在我们已经体验了下这个API，到时间用它来解决我们的问题了。
我们需要的是一个函数，其通过重设一个对象的一个或多个属性来修改一个对象（本例中为product），像这样：
Action<Product> baseReset = (Product p) => { p.Name = null; };
这段代码使用新的表达式API来创建一个等价的操作(action)：
var parameter = Expression.Parameter(typeof(Product));
var resetExpr = Expression.Lambda<Action<Product>>(
Expression.Block(
Expression.Assign(
Expression.Property(parameter,"Name"),
Expression.Constant(null, typeof(string))
)
),
parameter
);
var reset = resetExpr.Compile();
var product = new Product { ID = 1, Name = "Foo" };
reset(product);
果然当重置(product)被调用后，product的Name变为null。
步骤3 – 设定到所有的非键属性
现在我们需要做的只是创建一个函数，其接收到一个特定的CLR类型时将创建一个表达式来重置所有的非键属性。
实际上收集属性与它们期望的值的列表，对于本话题不是很重要，所以让我们想象我们已经将获得的信息放到一个dictionary中，如这样：
var properties = new Dictionary<PropertyInfo, object>();
var productProperties = typeof(Product).GetProperties();
var nameProp = productProperties.Single(p => p.Name == "Name");
var costProp = productProperties.Single(p => p.Name == "Cost");
properties.Add(nameProp, null);
properties.Add(costProp, 0.0M);
有了这个数据结构后，我们的工作就是创建一个与下面的Action有同样效果的表达式：
Action<Product> baseReset = (Product p) => {
p.Name = null;
p.Cost = 0.0M;
};
首先我需要创建所有的赋值表达式：
var parameter = Expression.Parameter(typeof(Product));
List<Expression> assignments = new List<Expression>();
foreach (var property in properties.Keys)
{
assignments.Add(Expression.Assign(
Expression.Property(parameter, property.Name),
Expression.Convert(
Expression.Constant(
properties[property],
property.PropertyType
)
)
);
}
接下来我们把赋值表达式注入Lambda内一个block中，编译整个项目并测试我们的新函数：
var resetExpr = Expression.Lambda<Action<Product>>(
Expression.Block(
assignments.ToArray()
),
parameter
);
var reset = resetExpr.Compile();
var product = new Product { ID = 1, Name = "Foo", Cost = 34.5M };
reset(product);
Debug.Assert(product.Name == null);
Debug.Assert(product.Cost == 0.0M);
正如期待的这很好用。
要解决这个问题，我准备放在更新的博文中，我们需要一个以类型为键dictionary，我们可以用其来存储一个特定类型重置动作。这样如果一个类型的重置动作没有找到我们只需创建一个新的…
并且性能问题应该已经成为过去J
提示55. 怎样通过包装来扩展一个IQueryable
在过去几年中，我在很多情况下都想要深入底层看看IQueryable内部到底发生什么，但我一直没有找到一个简单的方法，至少到目前为止。
像这样深入并做一些东西很有趣，这样你可以：
l 在查询执行前进行Log
l 重写表达式，例如替换一个提供程序-如EF, LINQ to SQL, LINQ to Objects等不支持的表达式为可以被支持的。
无论如何，我很高兴不久之前当查看Vitek（BTW，他的新博客在这）完成的一些示例代码，我意识到我可以将其一般化来创建一个InterceptedQuery<>与一个InterceptingProvider。
基本思想是使你可以这样使用IQueryable：
public IQueryable<Customer> Customers
{
get{
return InterceptingProvider.CreateQuery(_ctx.Customers, visitor);
}
}
此处visitor是一个会被访问的ExpressionVisitor，在将查询提交到底层（本例中就是Entity Frameork）之前，其可能会重写任何Customers组成的查询。
实现
多亏Vitek才使这个实现变得相当简单。
让我们开始实现InterceptedQuery<>，实际上这不值一提：
public class InterceptedQuery<T> : IOrderedQueryable<T>
{
private Expression _expression;
private InterceptingProvider _provider;
public InterceptedQuery(
InterceptingProvider provider,
Expression expression)
{
this._provider = provider;
this._expression = expression;
}
public IEnumerator<T> GetEnumerator()
{
return this._provider.ExecuteQuery<T>(this._expression);
}
IEnumerator IEnumerable.GetEnumerator()
{
return this._provider.ExecuteQuery<T>(this._expression);
}
public Type ElementType
{
get { return typeof(T); }
}
public Expression Expression
{
get { return this._expression; }
}
public IQueryProvider Provider
{
get { return this._provider; }
}
}
接下来是InterceptedProvider，这更有趣：
public class InterceptingProvider : IQueryProvider
{
private IQueryProvider _underlyingProvider;
private Func<Expression,Expression>[] _visitors;
private InterceptingProvider(
IQueryProvider underlyingQueryProvider,
params Func<Expression,Expression>[] visitors)
{
this._underlyingProvider = underlyingQueryProvider;
this._visitors = visitors;
}
public static IQueryable<T> Intercept<T>(
IQueryable<T> underlyingQuery,
params ExpressionVisitor[] visitors)
{
Func<Expression, Expression>[] visitFuncs =
visitors
.Select(v => (Func<Expression, Expression>) v.Visit)
.ToArray();
return Intercept<T>(underlyingQuery, visitFuncs);
}
public static IQueryable<T> Intercept<T>(
IQueryable<T> underlyingQuery,
params Func<Expression,Expression>[] visitors)
{
InterceptingProvider provider = new InterceptingProvider(
underlyingQuery.Provider,
visitors
);
return provider.CreateQuery<T>(
underlyingQuery.Expression);
}
public IEnumerator<TElement> ExecuteQuery<TElement>(
Expression expression)
{
return _underlyingProvider.CreateQuery<TElement>(
InterceptExpr(expression)
).GetEnumerator();
}
public IQueryable<TElement> CreateQuery<TElement>(
Expression expression)
{
return new InterceptedQuery<TElement>(this, expression);
}
public IQueryable CreateQuery(Expression expression)
{
Type et = TypeHelper.FindIEnumerable(expression.Type);
Type qt = typeof(InterceptedQuery<>).MakeGenericType(et);
object[] args = new object[] { this, expression };
ConstructorInfo ci = qt.GetConstructor(
BindingFlags.NonPublic | BindingFlags.Instance,
null,
new Type[] {
typeof(InterceptingProvider),
typeof(Expression)
},
null);
return (IQueryable)ci.Invoke(args);
}
public TResult Execute<TResult>(Expression expression)
{
return this._underlyingProvider.Execute<TResult>(
InterceptExpr(expression)
);
}
public object Execute(Expression expression)
{
return this._underlyingProvider.Execute(
InterceptExpr(expression)
);
}
private Expression InterceptExpr(Expression expression)
{
Expression exp = expression;
foreach (var visitor in _visitors)
exp = visitor(exp);
return exp;
}
}
注意任何时候查询被执行，我们拦截当前表达式，其中依次调用了所有已注册的’visitors’,然后在底层提供程序上执行最终的表达式。
实现说明：
在基础架构中我们的实现使用了Func<Expression,Expression>而非.NET4.0的System.Linq.Expressions.ExpressionVisitor，主要因为.NET对于社区来的稍显迟了， 所以当前很多visitor没有继承自System.Linq.Expressions.ExpressionVisitor。
你只需要再看一下Matt Warren的极佳的IQToolkit，里面有很多例子。
然而我们想鼓励使用System.Linq.Expressions.ExpressionVisitor，所以对此也有一个方便的重载。
同时记住如果你包装了Entity Framework，并进行了任何重写的比较复杂的查询，你需要避免任何调用表达式 – 见Colin的博文。
IQToolbox比较有用的visitor之一被称作ExpressionWriter及其带的一些小插件-其公开了所有构造函数与基础Visit方法-你可以使用它在Entity Framework查询被执行前将表达式输出到控制台：
CustomersContext _ctx = new CustomersContext();
ExpressionWriter _writer = new ExpressionWriter(Console.Out);
public IQueryable<Customer> Customers{
get{
return InterceptingProvider.Intercept(_ctx.Customers, _writer.Visit);
}
}
同样你需要留心我们在CreateQuery这个非强类型的方法中使用IQToolbox中有用的TypeHelper类，它确实帮助我们创建正确的泛型InterceptedQuery<>类型的示例。
再次谢谢Matt！
把这些合在一起：
展示最后一个例子。
这里我模拟WCF/ADO.NET数据服务的工作来处理这个请求：
GET ~/People/?$filter=Surname eq ‘James’
如果后端是一个非强类型的数据服务提供程序。
// Create some data
List<Dictionary<string, object>> data = new List<Dictionary<string, object>>();
data.Add(
new Dictionary<string, object>{{"Surname", "James"}, {"Firstname", "Alex"}}
);
data.Add(
new Dictionary<string, object>{{"Surname", "Guard"}, {"Firstname", "Damien"}}
);
data.Add(
new Dictionary<string, object>{{"Surname", "Meek"}, {"Firstname", "Colin"}}
);
data.Add(
new Dictionary<string, object>{{"Surname", "Karas"}, {"Firstname", "Vitek"}}
);
data.Add(
new Dictionary<string, object>{{"Surname", "Warren"}, {"Firstname", "Matt"}}
);
// Create a couple of visitors
var writer = new ExpressionWriter(Console.Out);
var dspVisitor = new DSPExpressionVisitor();
// Intercept queries to the L2O IQueryable
var queryRoot = InterceptingProvider.Intercept(
data.AsQueryable(), // L2O’s iqueryable
writer.Visit, // What does the expression look like first?
dspVisitor.Visit, // Replace GetValue().
writer.Visit // What does the expression look like now?
);
// Create a Data Services handle for the Surname property
ResourceProperty surname = new ResourceProperty(
"Surname",
ResourcePropertyKind.Primitive,
ResourceType.GetPrimitiveResourceType(typeof(string))
);
// Create a query without knowing how to access the Surname
// from x.
var query =
from x in queryRoot
where ((string) DataServiceProviderMethods.GetValue(x, surname))
== "James"
select x;
// Execute the query and print some results
foreach (var x in query)
Console.WriteLine("Found Match:{0}",
x["Firstname"].ToString()
);
如所见在一个字典列表中我们有一些People数据，我们试图找到姓氏为’James’的那个人。
问题是数据服务不知道怎样有一个字典中得到姓氏。所以它注入一个请求到DataServiceProviderMethods.GetValue(..)。
好。
不幸的是这时LINQ to Objects查询提供程序没有足够的上下文信息来处理这个查询 – 像我们在这个查询中这样盲目的调用GetValue会失败。
所以我们拦截这个查询，DSPExpressionVisitor（此处我将不深入）简单的将
DataServiceProviderMethods.GetValue(x, surname)
替换为这样：
x[surname.Name]
如果你查找形式，你可以看到这与下面的是相同的：
x["Surname"]
所以当整个表达式被访问时，你最终会得到如下这样的查询：
var query =
from x in queryRoot
where ((string) x[surname.Name]) == "James"
select x;
对于这个Linq to Objects可以很好的处理！
摘要
这是一个通用目的的解决方案允许将一个IQueryable叠加在另一个上，并在查询表达式被传入底层提供程序前翻译/重写/记录它。
Enjoy。