在使用WebService开发时，同时使用了EF和linq，查询数据时，使用linq（查询订单）可以正常拉出数据，
但是使用EF（查询用户）却会报以下错误：
{"指定的架构无效。错误: \r\nCLR 类型到 EDM 类型的映射不明确，因为多个 CLR 类型与 EDM 类型“Orders”匹配。以前找到的是 CLR 类型“WebService1.Model.Orders”，新找到的则是 CLR 类型“WebService1.LinqModel.Orders”。\r\nCLR 类型到 EDM 类型的映射不明确，因为多个 CLR 类型与 EDM 类型“Users”匹配。以前找到的是 CLR 类型“WebService1.Model.Users”，新找到的则是 CLR 类型“WebService1.LinqModel.Users”。"}
DbContext的MetadataWorkSpace一旦生成会缓存起来。也就是说，在同一个应用程序域里面，一旦用dbcontext操作过数据库，它会自动读取类所在assembly里面的所有类，并尝试匹配数据库模型，然后将匹配结果保存起来(保存到上面的MetaOCSpace中)。当下次操作数据库时，返回数据对应类类所在其它assembly里面的类与当前已匹配数据库模型发生冲突时，便会报错。（这段话是网上抄的）
在ASP.NET MVC5高级编程（第5版）中第70页作者写到：
实体框架的另一种（默认的）策略是延迟加载策略。使用延迟建在策略，EF在LINQ查询中只加载主要对象（专辑）的数据，而不填充Genre和Artist属性。
var albums=db.Albums;
延迟加载根据需要来加载相关数据，也就是说，只有当Album的Genre或Artist需要属性时，EF才会公国向数据库发送一个个额外的查询来加载这些数据。延迟加载策略会强制框架未列表中每一个专辑向数据库发送一个额外的查询。
参考上面的解释和报错信息，还是不太清楚他们的内部运行原理（需要继续研究），但是已经知道如何解决了。
解决方案：不要生成相通的模型，可以修改linq模型名称。
修改后：
问题得到解决。