I am saving a complex object graph from breeze, and I get the following error from the server:
Error: CROSS APPLY is not supported by Oracle
We are using an Oracle database using Devart provider. From my research, it seems that the only solution to this problem is to avoid certain linq query expressions. These threads provide further context:
http://forums.devart.com/viewtopic.php?t=18849
http://social.msdn.microsoft.com/Forums/en-US/adodotnetentityframework/thread/ae826dd9-1bab-4f64-a7ee-f082a2177346/
The last thread linked is particularly disheartening, as this appears to be a Microsoft-related EF issue on which they have gone dark on for quite some time.
Since the only remedy for this appears to be avoiding specific linq operators/expressions, I must ask if there is any way to use breeze and avoid these offending linq expressions? If not, I am lead to conclude that breeze is currently limited only to relational databases that are fully-supported by EF, which from the my research is effectively only MS SQL.
Hoping I am wrong,
Mathias
If you want to use Breeze's EFContextProvider then you are limited to using an EF backend. However you do some other options. The first is that you can pass your own parameters into your controller methods, ( see the EntityQuery.withParameters method). This may allow you to rewrite your expression on the server to avoid EF expressions that cannot be tranlated properly for Oracle.
In addition, you can use Breeze with your own custom context provider or you can take over the server side completely. The first is a good approach if you are talking to another .NET backend, the second is appropriate when you are talking to an arbitrary non .NET backend.
We are planning on releasing an NHibernate backend to breeze as well as a Node-MongoDb backend within the next few weeks to illustrate both of these.
Related
I have an EF model with about 200 tables, 75 of which I'd like to expose via REST in an MVC app. I started by adding a WCF Data Service (WCF-DS), pointed it to the EF context, and bam, I had the entire database mapped to REST URI's with full OData syntax support in about 2 minutes.
Next I tried to create the same REST URI space with WebAPI. When I tried to add a WebAPI OData Controller the first thing it asks for was a Model Class and when I was done creating the controller (and copying all the required ODataConventionModelBuilder code into the WebApiConfig) I only had one REST endpoint! My impression now is that WebAPI is not well suited to expose entire EF models with a lot of brute force.
So my questions:
Am I missing a way to map a bunch of WebAPI endpoints to a EF model in one fell swoop?
(Maybe T4 templates that build all the WebAPI code when I generate my EF model??)
Are there any compelling reasons to consider WebAPI vs WCF-DS to expose large URI domains?
(Some say that the benefits of WebAPI are to have fine grained control over each and every MVC/HTTP request but that seems counter-productive if the goal is to conform to the OData spec. I'm not sure I want to have 75 controllers and 1000's of lines of code that would tempt my dev colleagues to change one entity's behavior that would result in different behavior from other entities.)
(For cross cutting concerns such as security, caching, or performance throttling WCF-DS seems to have sufficient configure-ability with Interceptors and its DataServiceConfiguration class. Are there any features of WebAPI that would do better here?)
Thanks.
Update: I found this article by Julie Lermon that helps a bit: http://msdn.microsoft.com/en-us/magazine/dn201742.aspx
Since I have only exposed EF model using WCF DS, I can't comment on Web API questions. But we never really had a reason to replace WCF DS with Web API for our model because as you also noticed, EF and WCF DS play so nicely together that you basically get an OData feed for free. On a client side the situation is different: we started with WCF Data Services Client that is trying to mimic Linq to Entity Framework, but is has so many limitations that I ended up writing my own OData client (you can read about what made us unhappy with WCF DS client part here).
Coming back to server side: our domain was large, we had 80+ tables with almost 1000 columns. And we even supported all CRUD operations using batch updates (OData analog of transactions). While I would recommend to think twice before exposing database record update operations over OData protocol due to design principles, we haven't had any technical issues with that approach.
It is my opinion that Web API + OData extensions is highly overrated for a large majority or use-cases, and my argument is that OData is fundamentally data-oriented while Web API has come to become a great fit for general-purpose APIs, which include service-oriented APIs.
Your use-case is, I believe, a prime example of a very data-oriented layer since you don't seem to want to add much domain logic on this tier (server-side of this HTTP API). And WCF-DS works great for that, especially if you're merely wrapping an EF model which does 90% of the work for you (as you've already observed).
Of course it would be a different story if you were modeling more intricate processes at that layer (in that tier), so exploring both options like you did is always a very good idea. Normally the obvious choice should come naturally, either you'll be writing a lot of redundant code with Web API (go with WCF-DS) or you'll be fighting with WCF-DS's very rigid framework by playing with odd entities and not-very-RESTful OData actions (go with Web API alone).
Web API with its OData extensions stands somewhere in the middle, although it's not always clear what advantages it provides over custom WCF-DS providers. I guess it's nice for people who already know Web API or ASP.NET MVC, and may be a requirement if you want open source. I personally wouldn't debate on this technology with technical arguments, except for the few gotchas one should know about (but which have nothing to do with its design). I've ranted about all of this a while ago, should you want more, but I stress again that there are no hard truths in any of this -- discussing architecture and design is in no-trivial proportions a matter of opinions.
Update: WCF-DS was killed.
I have a silverlight application that communicates with the sql server database. The server side is a WCF RIA webservices that use EF 4 for persisting data back to db.
I am considering switching to RavenDB for two reasons
Scalability
Freedom from updating schema on production server.
My questions
How easy it is to switch to RavenDB. Is it as easy as pointing the connection toRavenDB.
Will it create a schema automatically by inspecting the entities.
can i continue to use linq in wcf. Or do i need to replace code in it?
Thanks,
Ankur
No. It will most likely require a model change since a model suited from RavenDB is usually very different from a relational model you're likely to be using now.
There is no schema with RavenDB.
Yes, but you'll probably need to rewrite the queries to match the new document-oriented model that you'll come up with for using RavenDB.
Here is my knowing about ASP.NET SPA:
have to use Upshot to talk to the server;
have to use DbDataController to provide Web APIs;
have to use Entity Framework Code first...
so, many concerns come out:
have to provide metadata for the upshot to work, this will obviously expose the structure of your database;
can i use Entity Framework Database First instead of Code First? You may ask why. Because Code First don't provide you the ability to customize your database(index customization, stored procedure...etc.);
A problem i met: when i add a "TestUpshot.edmx" file(generated from database 'northwind') to the MySpaApp.Models folder(trying to test whether i can use the edmx classes in the MyDbDataController class, and generate proper metadata in the client side), and run the application, there is an exception:"System.ArgumentException: Could not find the conceptual model type for MySpaApp.Models.Categories."...
Need help here, thanks in advance.
Dean
I may be missing something, but there is no requirement to use any of the technologies you've listed.
An SPA is just a pattern. You can use whatever you need to achieve that. There may be benefits with choosing certain technologies, ie templates, tutorials, etc.
Doesn't really answer your question, but should lead you to experiment with what you've got.
SPA is actually a way to conceptualize your client application. SPA comes the closest to the fat client - data server concept from the current web approaches. Definitely this will be the ruling concept within a couple of years.
Your concerns can be addressed using JayData at http://jaydata.codeplex.com that provides advanced, high level data access for JavaScript against any kind of EntityFramework back-ends (db, model or code first). Check out this video that presents the whole cycle from importing your EDMX from SQL (this could eighter be model first definition as well) to inserting a new product item in the Products table from JavaScript.
I am quite new to entity frame work 4.0 and what I know from my intial analysis is entity framework is nothing but an abstraction of ado.net with its storage model, conceptual schema and the mappping between these two.But one thing I am unclear is while fetching data from database or executing any stored procedure what mechanism its following.
Is it adopting the traditional ado.net approach or is it the concept of linq2sql?
The reason I am asking this question is in our project we are not suppose to use linq for some security reason (I am not sure what this security linkage is but we have not to follow linq relegiously).
So I just wanted to know how entityframework works for performing all its db transaction and whether by any chance it is using linq to sql?
Hope I was able to convey my problem. Please look into this and respond ASAP. I am in a kind of fix :(
Regards
Subrat
No - both Linq-to-SQL and Entity Framework make good use of the LINQ features in C#/VB.NET - but they're both totally separate projects.
Linq-to-SQL was created by the C# team, more or less as a "proof-of-concept" for how to use LINQ with databases.
Entity Framework on the other hand grew out of the database teams (ADO.NET team) at Microsoft and was designed from the ground up as a full-fledged, enterprise-ready system to be the "next big thing" after straight up ADO.NET
Why using LINQ (as a technology) should have any security implications is beyond me.....
Yes - with the Linq-to-SQL approach, your application needs direct access to all underlying tables - read and write. But with EF in version 4, you can do very safe styles of work:
SELECT only from views exposed in the database
handle all the CUD operations (INSERT, UPDATE, DELETE) by wiring up your EF entities to stored procedures
With this, your applications don't need direct table read/write access at all - no different than when manually using SELECT from views and stored procedures for all other operations.
I am starting out on a project that will involve ASP.NET MVC using a legacy ODBC 2.0 compliant database. The goal is to replace current system functionality with a web front end over a period of maybe a year then swap out the backend with SQL Server.
The plan would be to code against SQL server then insert some shim into the repository classes to use ODBC instead. Is it even feasible to do this ? Entity Framework doesn't have built in support for ODBC.
Any thoughts or advice would be appreciated.
I personally use NHibernate with MVC. Originally I picked it up because our database doesn't support EF but enjoy it enough that even if we moved to SQL Server I'd keep NHibernate.
The learning curve is kinda weird. It is definitely steep to become an expert, but it is interesting in that it is pretty organic to let it handle more and more of the work for you as you get comfortable with certain layers.
So for your case NHibernate probably supports your database, can be used as a simple data access layer (just returning DTOs), provides a database agnostic interface and can support SQL Server when the time comes. If you end up wanting more out of NHibernate it is there when the time comes.
There's nothing to stop you writing your own data access layer, to query the ODBC Database. You could also make your own entity layer so that the MVC model can populate your entities using the data layer, and return these objects to the controller.
Basically, have a data access and entities layer under your mvc app, then you can replace these entities, with entity framework, or nhibernate entities, at a later date.
This way of doing it means that your MVC app doesn't need to know what database it is using, it also means that you should have an easy time when you switch an entity later.