can Entity framework 4.0 works with any database by changing connection string?

I want to know if I develop and application using entity framework 4.0 and sql s开发者_开发技巧erver and then changing the connection string to my sql one, will it work without any problem?

What are the other considerations to keep in mind?

---

No, i dont think that is not enough.

AFAIK - the core LINQ providers for Entity Framework (ObjectQuery<T>) are designed for SQL Server provider.

My advice would be to encapsulate your logic behind a Repository, and keep your interface very high-level (no EF dependance):

public interface IRepository<T> where T : class
{
   public T FindSingle(int id);
   public ICollection<T> FindAll(Expression<Func<T,bool>> predicate);
   public void Add(T entity);
   public void Remove(T entity);
}

Then implement your SQL Server implementation using the EF LINQ providers (e.g SqlServerRepository<T> : IRepository<T>). Then when you switch over to MySQL, implement another repository implementation (e.g MySqlRepository<T> : IRepository<T>)

Key is don't use things like IQueryable<T> for your Repository, as this allows LINQ code to be applied to your DAL, which may not be applicable for both SQL Server and MySQL.

---

Just changing the connection string won't be sufficient as EF by default implements a provider that emits SQL Server specific T-SQL. There are other EF providers (although last time I looked they were only in beta) including one for Oracle and MySQL which will correctly translate your LINQ queries to db specific T-SQL.

---

If you are talking about changing the database connection to switch between SQL Server then that works fine.

If you want to switch between different database systems - e.g. Oracle, MySQL etc. then you'll need a provider... and you'll need to modify the storage types for each field to match the constraints of the underlying system.

You might want to check out the EF CTP for Code First which is capable of regenerating the storage layer at runtime by talking to the provider to find the best storage type match given the CLR type.