LINQ to Oracle or Entity Framework?
LINQ to Oracle or Entity Framework?
Hi,
I am looking at possibilities to use the ADO.NET Entity Framework to access Oracle databases.
1. I see that there is support for the ADO.NET Entity Framework and there is also the possibility to use LINQ to Oracle.
Is there any guidance on selecting the ADO.NET Entity Framework or LINQ to Oracle?
2. Is there a list of supported and unsupported entity sql canonical functions. E.g. there is documentation for the MS SQL Server provider for the entity framework (http://msdn.microsoft.com/en-us/library ... .100).aspx). This documentation shows how the canonical functions are mapped to SQL Server functions or a SQL Server implementation. Does this documentation exist for the DevArt provider.
3. I understand that the DevArt provider doesn't work with VS2010 Beta 2 (combined with the CTP2 of the entity framework). Is there an indication of when the support for the latest version of the .NET 4.0 framework will be available?
Kind Regards,
Patrick
I am looking at possibilities to use the ADO.NET Entity Framework to access Oracle databases.
1. I see that there is support for the ADO.NET Entity Framework and there is also the possibility to use LINQ to Oracle.
Is there any guidance on selecting the ADO.NET Entity Framework or LINQ to Oracle?
2. Is there a list of supported and unsupported entity sql canonical functions. E.g. there is documentation for the MS SQL Server provider for the entity framework (http://msdn.microsoft.com/en-us/library ... .100).aspx). This documentation shows how the canonical functions are mapped to SQL Server functions or a SQL Server implementation. Does this documentation exist for the DevArt provider.
3. I understand that the DevArt provider doesn't work with VS2010 Beta 2 (combined with the CTP2 of the entity framework). Is there an indication of when the support for the latest version of the .NET 4.0 framework will be available?
Kind Regards,
Patrick
1. In general, if you have a single-database application, LINQ to Oracle will suit better because
it is more close to database level. If you have an application that needs cross-database data model,
EF is the only option.
2. We provide support for a significant number of Oracle functions, but documentation for them is not ready yet.
3. We are working on Visual Studio 2010 Beta 2 support. Unfortunately, we cannot provide
a definite timeframe at the moment.
it is more close to database level. If you have an application that needs cross-database data model,
EF is the only option.
2. We provide support for a significant number of Oracle functions, but documentation for them is not ready yet.
3. We are working on Visual Studio 2010 Beta 2 support. Unfortunately, we cannot provide
a definite timeframe at the moment.
-
- Posts: 29
- Joined: Wed 07 Oct 2009 07:24
-
- Posts: 29
- Joined: Wed 07 Oct 2009 07:24
For example, here a problem, concerning OUTER APPLY translation, is discussed on our forum.
http://www.devart.com/forums/viewtopic.php?t=13258
Also, LINQ to Entities does not support methods like Single or SingleOrDefault.
http://www.devart.com/forums/viewtopic.php?t=13258
Also, LINQ to Entities does not support methods like Single or SingleOrDefault.
Getting the data out of the database and into objects is only half the problem. The second half, especially in Silverlight, is getting those objects to the client. By far the easiest way to support a Silverlight client is by using the Ideablade Devforce product with the Devart dotConnect for Oracle drivers. It has been a lot of hassle being on the bleeding edge with all three technologies, but they have all stabilized a lot in the past few months. We are now using Devart's Entity Developer as a total replacement for the MS Entity Framework editor and Ideablade then extends those Entity Framework objects with a lot more eventing and a lot of additional business app. functionality.
Taken as a set, the functionality provided by these products is far and above what I can get from Linq to Oracle and saves me from writing a TON of infrastructure code.
Taken as a set, the functionality provided by these products is far and above what I can get from Linq to Oracle and saves me from writing a TON of infrastructure code.