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.
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'm currently developing a Node.js app that needs to be able to switch between PostgreSQL and SQL Server databases. Both databases have identical tables and the operations will also be identical (basic CRUD, nothing fancy).
I've done research, and know that there are enough libraries around to access both databases.
Ideally I'd like to use a ORM and just let that handle the differences. However, I can't seem to find an ORM framework that does both. In fact, I can't locate any ORM that supports SQL Server, while almost all support Postgres.
So my question: is there an ORM that supports both? And if there isn't, are there other abstraction tools/frameworks around that will make my developer life easier?
There is a certain amount of YAGNI here, but if you are unable to find an ORM that supports both, your next best bet is to just use an Adapter Pattern and ensure you're not using the ORM directly in your code, but through a wrapper. Then if / when you need support for SQL Server, you can create the implementation for the wrapper which will replace the PostgreSQL implementation.
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.
Our client wants to support both SQL Server and Oracle in the next project. Our experience comes from .NET/SQL Server platform. We will hire an Oracle developer, but our concern is with the DataAccess code. Will NHibernate make the DB Engine transparent for us? I don't think so, but i would like to hear from developers who have faced similar situations.
I know this question is a little vague, because i don't have Oracle experience, so i don't know what issues we will find.
You can easily use NHibernate to make your application database-agnostic by following some basic practices:
Design your object model first.
Do not use any database-specific code. You need somebody with good C# experience, not an Oracle developer. Do not rely on stuff like triggers, stored procedures, etc.
Let NHibernate generate the DB schemas at least initially (you can tweak things like indexes later) It will choose the best available datatypes for each DB.
Use a DB-agnostic POID generator (hilo or guid) instead of sequences or identity.
Try to avoid using SQL. HQL and Linq work fine in 99% of the cases.
Avoid NH features that are not supported by all of your target DB (for example, Future, MultiCriteria, etc)
NHibernate has a great community. You can always ask your questions in http://groups.google.com/group/nhusers besides posting here.
There are three things to consider - the ISession object, the SQL queries that are generated and your plain-old-clr-objects that are mapped to tables.
NHiberante will generate the required SQL queries based upon the chosen database dialect. If you configure NHibernate to use the SQL Server dialect it will generate SQL server correct SQL statements. This can easily be configured dynamically at runtime based on configuration.
You also need to configure your session to connect to the right type of database. Again, various configuration methods can support dynamic ISession creation at runtime.
Your actual data objects which are mapped to tables should not need to change based on database choice. One of NHibernates strengths is flexibility it provides in supporting multiple databases via a (fairly) simply configuration change and some up-front architectural thought.
See http://codebetter.com/blogs/karlseguin/archive/2009/03/30/using-nhibernate-with-multiple-databases.aspx for some examples of how you might abstract the underlying database away from the creation and usage of NHibernate.
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.