I know there is a OA vs EF4 table on the website, but I specifically want to know OA vs EF5.
The project will reside on Windows Azure and use Windows Azure SQL Database. I will migrate it to .NET 4.5 once 4.5 is live on Azure.
Does anyone in the know have any pros/cons for this scenario? I am slightly leaning towards Telerik OpenAccess at the moment.
Thanks
4 Answers, 1 is accepted
Entity Framework 5 is currently introducing many new features. OpenAccess has a match for most of them, and some we have been offering for years - like support for enums, multiple results sets for stored procedures, spatial types (SqlGeometry, SqlGeography), changing the colors of the visual designer entities, etc. Others we don't have yet, but we are already planning and implementing. A good example is the support for table valued functions, which will be added in our next official release.
SQL Azure is supported by OpenAccess ORM so you can directly give it a try.
Do not hesitate to get back to us if you have any questions regarding the features you would be using in your projects - we can provide you with the needed information, example scenarios and deeper explanations, in order to ensure you are confident with the product before you start using it.
Ivailo
the Telerik team
Rank 1
In the last version of our product, we were using TFS (for VS2010) and EF4. We had so much trouble with it, it became a huge time-suck. Simple things, like updating databases required manual coordination and scripting. I know there are some more features in EF for 5 but these are not as important to me as 1) performance and 2) productivity. 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.
The other issue we had was surfacing EF into WCF JSON was a nightmare. First, if you try to simply send or receive EF objects through JSON, you will encounter a number of errors that require architectural changes to accomodate. For example, if your object graph gets more than 3 deep, you are going to have problems. Also, the EF property naming in JSON reads like a GUID. We eventually used T4 (got it from CodePlex to solve this very issue) to generate JSON wrappers and then shuttled them in and out of requests. So, think about the nightmare of 100s of JSON requests and responses being shuttled through wrapper classes. With OA, we can simply surface an OA class right into our WCF method. We actually didn;t have to change a thing and the JSON serializer eats the OA objects no problem.
The only caution I would give you is that you need to pay attention to performance when using OA. (This is also true of EF but since we stopped using that ...) In OA, I have noticed that the optimization and SQL generation is not always very good. Once you understand what queries generate sub-optimal code and which ones really go fast, you can design appropriately.
Overall, I and my team are glad we switched to OA. We'd like to see Telerik continue to work on performance but in the mean time, you get a very useful product and good support. I looked at the feature list for EF 5 when we were deciding whether to switch or not - in the end, we could n;t tolerate the loss of productivity and were willing to put OA in place rather than get burned by even more features.
Good luck,
Peter
Rank 1
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.
See this 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.
I would like to thank you both for sharing your experience with OpenAccess. It is in fact very valuable to us. All and all I have to agree that there isn't a best tool in terms of an ORM. It is very important for one to carefully examine all of the options available and select the one that makes more sense for the current project.
It is true that we do certain things better than Entity Framework and it is also true they can do some stuff we cannot. That is why I am so glad that we have got two un-biased and well thoughout opinions on the matter. This will certainly be helpful for people that are evaluating an ORM tool now and in the future.
As to the issues you have found out, we will certainly try and fix as many of them the best way we can for the next quarterly release.
Again thanks for taking the time to share your experience with us and with the community.
Serge
the Telerik team