OData's $metadata is based on EDM/CSDL, but with Entity Framework 7, EDMX is going away, replaced with code-first (or whatever they decide to call it).
This makes me wonder about using $metadata and the related CSDL spec, which might be at a dead end now. Do you have the same concerns or should I go head first into OData and enjoy its [maybe] short lived support from Microsoft.
OData v4 has just been published as a new OASIS standard, they're not going to drop support for it anytime soon.
The OData team have said that they have not even started working on K-Runtime version yet, I cant find the quote, but basically they mentioned that both the MVC6 and EF7 projects were evolving so rapidly that they were going to wait until things were stablized before implementing it, So it may be some time yet.
Related
We implemented a web application using EF 4.0 and ObjectContext. Now we would like to upgrade it to Ef 5 to get benefit of the performance improvements and new features, as described in Julie Lerman's
article.
From the Infrasctructure point of view, the passage seems pretty smooth:
- Target the project to .NET 4.5 (if new features like ENUM support are needed)
- Upgrade/Install EF 5
However I could not find on the net good articles speaking about the needed steps and connected risks in passing from ObjectContext to DbContext.
As for now, my approach would be to create a separate code branch and upgrade EF there. Then substituting ObjectContext with DbContaxt API and refactor arising errors.
Actually DbContext is a wrapper on top of ObjectContext developed to help developers in coding, therefore the exchange should (hopefully) be relatively smooth. We also use an interface as single point of contact to the Model, therefore this should also help to narrow down the required changes.
Does anyone know the if/when/where behind the self-tracking entities template for the latest version of EF? Our team would like to move forward to be able to take advantage of the performance improvements that the EF team has documented, but we haven't been able to find any reference to the new T4 templates for self-tracking entities, which we are dependent upon.
We've tried firing up the old template, but the framework has changed too much.
There's a thread on MSDN about it, but it has not been updated in a while. (http://social.msdn.microsoft.com/Forums/en-US/adodotnetentityframework/thread/4993d0bf-94e8-4d14-aff1-3458b4ad467f/#889cc5f1-e267-448a-ae82-e3d705b7dfa5)
Thanks.
You can download it from here, they are available now.
I've used "EF Provider Wrappers" made by Jarek Kowalski. It works fine but I noticed "Limitations and Disclaimers" section where it says:
The providers have not been extensively tested beyond what’s included in the sample code, so you should use them at your own risk.
As with any other sample, Microsoft is not offering any kind of support for it, but if you find bugs or have feature suggestions, please use this blog’s contact form and let me know about them.
I'm little confused here, Does Microsoft really expect developers to use EnityFramework on production websites without any official support (or recommendation) for 2nd level Caching?
There is no official 2nd level cache support. I'm even not sure if EF Provider wrappers are compatible with .NET 4.5. 2nd level cache is in backlog for future versions of EF.
You can also implement your own solution because EF is fully open sourced.
Btw. I have seen dozens of quite complex web sites running in production without any cache ...
There is now a 2nd level cache provider available for EF 6.x
Entity Framework does not currently support caching of query results. A sample EF Caching provider is available for Entity Framework version 5 and earlier but due to changes to the provider model this sample provider does not work with Entity Framework 6 and newer. This project is filling the gap by enabling caching of query results for Entity Framework 6.1 applications.
https://github.com/moozzyk/EFCache
And Redis provider implemented on top of it :
Extends EFCache by adding Redis support
I wanted to add L2 Cache to EF using Redis - there was nothing
available at the time.
I found EFCache written by Pawel Kadluczka (moozzyk) over on CodePlex
https://github.com/silentbobbert/EFCache.Redis
Apache Ignite.NET provides a distributed in-memory 2nd level cache for Entity Framework: https://apacheignite-net.readme.io/docs/entity-framework-second-level-cache
I have started working on a new project and am switching from LinqToSQL to EF 4.1 as my ORM.
I already have a database set up to work with and so am going with the database first approach. By default the EF generates a context which extends ObjectContext. I wanted to know if a good approach would be to replace it with DbContext.
Most of the available examples deal with only Code First and DbContextbut DBContext can be used with Database First too. Are there any advantages I get by using the DBContext? From what I have read the DBContext is a simplified version of the ObjectContext and makes it easier to work with. Are there any other advantages or disadvantages?
You will not replace anything manually. You will need DbContext T4 Generator available at VS Gallery. Don't touch your autogenerated files - your changes will be lost every time you modify EDMX file.
I answered similar question last year. Now my answer is mostly - for new users DbContext API is probably better. DbContext API is simplified - both in terms of usage and features but you can still get ObjectContext from DbContext and use features available only in ObjectContext API. On the other hand DbContext API has some additional performance impact and additional layer of bugs. In simple project you will probably not find any disadvantage in DbContext API - you will not see performance impact, you will not use corner features available only in ObjectContext and you will not be affected by occasional bugs.
A lot of information and blog posts was collected since DbContext API was released so you don't have to be afraid that you will not find description of the API. Also ADO.NET team now uses DbContext API as their flag ship.
I'm not a big fan of DbContext API but my opinion is not related to its functionality but to its existence - there is no need to have two APIs and split development capacity of ADO.NET team to maintain and fix two APIs doing the same. It only means that there is less capacity for implementation of really new features.
I'm using it now with Oracle on an add on to an existing application. The simplification that Ladislav refers to works well for me on this project as I am short on time and resources. I have not found any gotchas as long as you stick to simple CRUD operations and less than ~150 tables.
You can still use metadata annotations to provide basic validation and localization and there is enough documentation out there but you won't find much on official Microsoft sites.
I'm writing a business application using Entity Framework and there are some things that I need like:
transaction and transaction scope management **
data filtering
control over refreshing data from the db (eg. every 15 s)
be able to manage what changes are being made to the data and to be able to undo some of them
Those things aren't supported in any way by Entity Framework (or at least it's not easy to accomplish it).
Are there any libraries that sit on top of EF and can do that (or maybe they have their own ORMs) ?
Do I really have to implement that myself?
** I mean something like: I have an object and want to do some changes to it - I start a transaction and every change that is done from that point in time is included in the transaction, then I commit and that's all that gets commited to the db - other objects live their own happy lives.
Wouldn't any standard ORM do all that for you? Both Hibernate and SQLAlchemy (the big ones I've worked with so far) will do all that stuff for you. They both support transactions, versioning, filtering is straightforward and both support rollbacks during transactions.
For rapid business application development, have a look at Spring Roo, Entity Framework sounds like something that is not ready for the market, Spring is.
Quote from wikipedia: The first version of Entity Framework (EFv1) was included with .NET Framework 3.5 Service Pack 1 and Visual Studio 2008 Service Pack 1, released on 11 August 2008. This version has been widely criticized, even attracting a 'vote of no confidence' signed by several hundred developers.