I am investigating for different ORMs to use in a new Web Application I have to develop.
I hesitate between NHibernate and EntityFramework 4.1.
I know that NHibernate does support different databases (like SQL Server, MySQL, Oracle, and so on.) isn't it?
What about Entity Framework? I cannot find which databases it supports (I suppose it is database agnostic but I am not very sure). For example, I was not able to make it run with MySQL (with MySQL Connector 6.4.3).
The answer I want is only regarding on the support of differents databases. There are some information in stackoverflow about "NHibernate vs Entity Framework".
Entity Framework query is translated into final form (sent to DB) by three "layers":
1. Object Services
2. EntityClient Data Provider
3. ADO .NET Data Provider.
The Object Services layer is a component of the Entity Framework that enables you to
query, insert, update, and delete data, using common language runtime (CLR) objects that
are instances of entity types.
The Entity Framework includes the EntityClient data provider, which manages connections, translates entity queries into data source-specific queries, and returns a data reader the Entity
Framework uses to materialize entity data into objects.
Traditional ADO.NET is still used to communicate to the underlying database.
What does it mean? It means Entity Framework was designed to be database independed. You can use it with every database if database provider has created provider for ADO .NET (which exists for MySQL, Oracle etc.).
For MySQL you should be able to use EF with connector that you've mentioned (more info: http://dev.mysql.com/doc/refman/4.1/en/connector-net-visual-studio-entity-framework.html)
Out of the box NHibernate supports following:
Microsoft SQL Server (including Compact Edition)
Oracle
Microsoft Access
Firebird
PostgreSQL
DB2 UDB
MySQL
SQLite
Corresponding ADO.NET provider needs to be installed. In addition to ADO.NET provider, NHibernate needs its own 'driver' and 'dialect' if you want to extend it to support the database that is not on the list.
Related
We have a few .Net application that we would like to start using Entity Framework 5.0 but the problem is that our customers can choose to use one of any of the following database engines:
SQL Server (95% of Customers use this engine)
Oracle (3% use this engine)
DB2 (2%)
So as you can see an overwhelming majority of our customers use SQL Server. So my question is that assuming that each database engine will have the same exact schema layout then all we should have to do is to change the entity connection string to target each of these engine types, correct?
Sorry if this seems to be a simplistic question but I just wanted to make sure that I was on the right track here.
I do not know Entity Framework, but the are many differences between the DB engines.
For example the security, in DB2 is always external (OS secutiry), in Oracle most of the time is internal. Procedure language is different, and I hope you don't use it for a multi-platform application.
The best is to try the execution with each database, and tune the procedure in order to work in all of them, but I think you have to do more that change the connection string.
I am looking to use Entity framework as database layer in my application, but I found that it didn't support oracle database and I will need to use third party provider for this purpose.
However I want to build database layer support multiple database (Oracle , MS Sql Server) and in the same time support entity model like LinqToSql and devart.
if any one has any information can help me I will be grateful.
Thanks.
What you want here is probably a repository pattern, something that can sit in the middle so that your application doesn't care how the underlying data is stored.
You could use something like my repository pattern (read about it here : http://blog.staticvoid.co.nz/2011/10/staticvoid-repository-pattern-nuget.html) and implement a custom IRepositoryDataSource for oracle (you could do this by using the LINQ to oracle provider from codeplex, http://linqtooracle.codeplex.com/) or alternatively you could write your own repository with implementations for both sql and oracle.
I found that linqconnect component from (devart) does what I need.
Entity Framework does not include an out-of-the-box provider for any RDBMS other than SQL Server. Any third-party RDBMS vendor that wants to support EF is expected to provide its own implementation based on Microsoft's provider model. Oracle has in fact released an official provider that is part of ODP.NET. I would recommend this one because it is free:
http://www.oracle.com/technetwork/issue-archive/2011/11-sep/o51odt-453447.html
P.S. - The Devart LinqConnect providers are not really Linq to SQL providers. They provide classes that mimick the structure and functionality of the Linq to SQL classes (DataContext, EntitySet<T>, etc.), but they are in a different namespace. It is impossible for anybody other than Microsoft implement a Linq to SQL provider, because they never exposed the provider model through public types.
I've been working on an ASP.NET Entity Framework 4.3 Code-First application, which governs the model for the parts of the database it cares about. As this database will be used by multiple other applications (some not using ef so can't import models) the idea was to create the base database with my application. After this the DBA could add other fields and tables not used by my application as necessary.
The problem arrises when implementing changes to the model in my application. Our idea was to use the new Migrations feature of EF 4.3 to create scripts (-script feature) while pointing to our local machine dev db (SQLCompact), which will then be passed to the DBA for migrating the actual dev database (MS SQL 2008) that all of the other applications use.
This has been causing problems though, as when I began testing (pointing to SQL server) the application couldn't read any foreign key relationships, giving errors that these columns don't exist. I'm wondering if this is caused by the differences in translation of SQL Compact and SQL Server (EF to SQL), or some other problem is the cause.
Should I be bothering with EF migrations for this type of 1-DB multiple App environment at all? Do I need to run all my migrations directly against the SQL Server? Is there an entirely different change strategy I should be using? Any help or guidance would be appreciated.
Well, you could try installing SQL Server Express locally instead of using compact. That should get rid of any differences there might be between compact and standard.
I'm relatively new to .NET but I'm trying to determine if it's possible to have a single .NET 4 application connect to multiple vendor databases simultaneously (SQL Server, Oracle, DB2 and MySQL) using ADO.NET and execute queries simultaneously?
All the examples I've found so far talk about connecting to only one database at a time.
Thanks!
You just need 4 connections strings and 4 separate ADO Connection objects. And then what SLaks said about async queries to do them simultaneously, if you truly want them running in parallel.
You can execute two queries the same way you execute one query.
If you want them to execute two queries at once, you'll need to make asynchronous queries or use threads.
The ADO.NET framework defines an abstract set of 'DbXXX' classes like DbConnection,DbCommand etc, which are implemented by various database providers such as
System.Data.SqlClient.SqlConnection' in the System.Data.dll for Sql Server
'Oracle.DataAccess.Client.OracleConnection' in the Oracle.DataAccess.dll (ODP.NET provider) for Oracle
'MySql.Data.MySqlClient.MySqlConnection' in the MySql.Data.dll for MySql etc
You then need to design your apllication against the abstract set of classes and use appropriate implementations wherever required. Most of the queries should work against all the backends but there will obviously be backend specific tweaks, not to mention stored procedure calls.
Alternatively you could use an ORM (Entity Framework, Telerik OpenAccess ORM, NHibernate etc) and abstract much of this difference to the ORM. Although I am not sure you can use a single entity model (in EF) against multiple backends.
We are writing this paper about database access in a web app and have to distinguish between the different categories of the database access layer.
All books and PDF's given us provide only information to JDBC or OLEDB.
Researching on the web brought me to the point that access to a Microsoft SQL Server trough linq-to-entities or linq-to-sql through ADO.Net can't be put under the same category as JDBC or OLEDB (middleware).
What would be the exact definition/category for Microsoft SQL Server-access through the .NET facilities such as LINQ2Entities or LINQ2SQL?
ADO.NET is the next step after OleDB - and it's definitely in the same category as OleDB or ODBC / JDBC.
Linq-to-SQL and Linq-to-Entities are more high-level - they don't solve low-level data access problems, they're more about OR-mapping and providing models to work against. I would put those in a similar category as Hibernate in the Java world.
Marc
LINQ to SQL and the Entity Framework both fit (to varying degrees) in the category of ORMs. Both sit on top of ADO.NET and cannot be used without it. ADO.NET is essentially a .NET replacement for OLE-DB, which, itself, was a replacement for ODBC.