1.我的环境VS2008 SP1.Entity Data Model Wizard里选DataSource时不能选择Acess的数据库.是否目前不能建Acess的Entity Data Model.
相反Linq to Sql可以.
2.ADO.NET Entity与Linq to Sql 相比,有啥些优点.对于中小型项目,以及它们的适应情况
答:
1. 至今为止，微软官方尚未发布EF Provider for Access/ODBC。
ADO.Net Entity Framework 的 Data Provider 可以根据不同目标数据库来进行自定义开发。Provider开发的关键在于适合于各个目标数据库的SQL语句的翻译。在MSDN Code Gallery上有Entity Framework Sample Provider开发的实例程序，以下链接可供参考。
a. http://code.msdn.microsoft.com/EFSampleProvider ; Entity Framework Sample Provider
b. http://code.msdn.microsoft.com/EFOracleProvider Sample Entity Framework Provider for Oracle – Home
c. http://blogs.msdn.com/adonet/ ; ADO.Net的Team Blog，有大量关于EF或者Provider发布的信息。
2. ADO.Net Entity Framework 与Linq to SQL的比较和适用场景：
MSDN上最近发表了一篇Elisa Flasko著的文章，比较了LINQ to SQL与LINQ to Entities适用的场景:
Introducing LINQ to Relational Data
http://msdn2.microsoft.com/en-us/library/cc161164.aspx
作者指出，LINQ to SQL主要的应用场景是针对微软SQL Server数据库的快速开发，这些应用的对象模型与数据库中数据定义的结构间非常类似，几乎有一一对应的映射关系，这样你可以使用LINQ to SQL把一些数据表直接映射到.NET类，数据字段映射到的相应的.NET类的属性上。作者总结如下：
LINQ to SQL适用之场景
.想使用ORM方案，而且数据库数据定义与对象模型是1：1对应关系
. 想使用ORM方案，而且对象继承结构储存在单一数据表中（单表继承）
. 想使用原始CLR类，而不是使用生成的类或需要从某个基类继承而来，或者需要实现某个接口
. 想使用LINQ来编写查询
. 想使用ORM，但需要性能非常好，可以通过存储过程和编译的查询来优化性能
LINQ to Entities主要的应用场景针对的是需要非常灵活和更复杂的映射的场景，特别是在企业应用方面，而且需要访问其他的数据库系统。在这些场景中，数据表的结构与对象模型也许差别很大，而且应用开发人员往往并不拥有生成或修改数据库数据定义的权利。
LINQ to Entities适用之场景 :
.想要开发针对微软SQL Server或其他数据库系统的应用
. 想要定义领域模型，并以之为持久层的基础
. 想要使用ORM方案，对象也许与数据库数据定义有1:1对应关系，也许结构迥异
. 想要使用支持单表继承和其他储存方案（每类一表，每具体类一表）的ORM方案
. 想使用LINQ来编写查询，并且查询可以在不同数据库系统下工作
. 想使用ORM，但需要性能非常好，可以通过存储过程和编译的查询来优化性能
刘江涛[MSFT]
在线开发支持工程师
合作伙伴支持部
微软全球技术支持中心