Just my $0.02 on some parts.
The other issue we had was surfacing EF into WCF JSON was a nightmare.
I actually did the same with OA and MVC/WebApi, and ultimately I had to whip up wrapper objects for pretty much everything or else OA would pull the entire (!) database into memory due to lazy loading (objects reachable to be exact) while the objects were being serialized. This has only been remedied in a recent OA release with the detach API. In EF: flip a single switch to disable lazy loading and you get exactly what you query for, exactly when you evaulate the query.
One more thing: Microsoft's Json implementation (up to MVC4 RC) is rather poor, e.g. it does not handle circular references. Since both OA and EF entities have two-way navigation properties (unless you seriously tweak your model) this will lead to a nice overflow.
When it comes to productivity, OA beats the stuffing out of EF. We maybe have had two or three instances where we have to open up the background XML file for OA and manually fix something. In EF, we lost time each instance where we made table or index additions.
issue I've posted recently. This pretty much means that for each model update I have to tailor the xml, open the designer and make the changes then tailor the xml again. Every saving results in a rather slow code generation pass. Not fun. Even less fun when I see 15 identical named entries in the SP list and have to guess which is which. (Some of this might have been fixed in Q2 SP1, have not checked yet.) And of course there's the new split diagrams
coming in EF5 which might or might not be implemented
in OA. (Note: only the diagram is split, not the model)
For the most part, I find EF and OA more or less on par. Some notable differences:
- Performance: OA has a huge advantage here, I'm measuring a 30-40% on some queries. EF5 is coming with nice optimizations but my guess is it won't be enough to bridge the gap. Note: theese are simpler queries, and semantically the same, it does not mean OA emits more efficient sql.
- Framework: OA is .NET 2.0+. EF5 is .NET 4.5, period. There are issues
around 4.5 that might hamper adoption.
- Updates: another great disadvantage to EF. Currently the EF runtime is tied to the .net framework, so new releases are years apart. There are plans to separate EF from the core framework thus speed up the release cycle, but not until EF6. Years away.
- Query expressions: EF has much better support for complex queries, but you cannot make it to translate unsupported stuff. In this case OA splits the query and evaluates parts on the client. This is nice in that you can do more complex expressions in the projection phase (which EF painfully lacks), but you have to closely monitor your logs or possibly ship a product that pulls thousands of rows for an aggregation that should only pull a couple.
- User defined functions: currently OA only supports stored procedures whereas EF4 supports scalar functions, and EF5 adds support for composable table valued functions. However function support is coming soon to OA.
For me there's no clean winner. There are attractive features and painful deficiencies on both sides.