EF7 - Priorities, Focus, and Initial Release
We all know, you don’t get to write software in a vacuum. Aside from the technical task we are trying to achieve there are things such as dependencies, stakeholders, release dates, etc. that impact the order and priority of tasks we do. In this post we wanted to share the top factors influencing the features and scenarios we focus on first.
Where are we at?
Up until recently we’ve been focused on validating our “New Platforms, New Data Stores” vision for EF7. This has meant building out a core framework, experimenting with patterns to support data stores with different capabilities, and implementing providers to validate our work.
In terms of data stores, we have experimented with SQL Server, SQLite, InMemory, Azure Table Storage, and Redis providers. We’ve also had discussions with other folks looking at DocumentDB, SQL Compact, and MongoDB providers.
For platforms, we have targeted traditional .NET Framework applications (WPF, WinForms, Console, and ASP.NET 4), Phone/Store/Universal, and ASP.NET 5 (a.k.a ASP.NET vNext).
The vision for EF7 is “a core framework that handles concepts common to most data stores with provider specific extensions that become available when you target a specific provider”. At this stage we feel confident that our architecture works well for our initial scenarios/providers and can evolve to accommodate future requirements.
What’s next?
Now that we are confident we are building the right thing, it’s time to start working towards a product that developers can use to write real applications with.
This means we need to focus on tasks such as completing functionality, improving quality, ensuring performance, adding logging, exploring usability, etc.
One approach to this would be to plug away until we have a production ready product for all providers and platforms that has all the standard features that we expect from an O/RM (of course, with plenty of previews along the way). If we operated in a vacuum, this is the approach our team would choose to take as it would mean we would launch with the best possible product. However, in the real world we have a series of partners and commitments that mean we need to focus on meeting these goals in incremental steps.
What’s our top priority?
Our team’s top commitment is to provide a data access stack for ASP.NET 5. Because ASP.NET 5 allows apps to target CoreCLR, the existing EF6.x product cannot provide this functionality (as it does not run on CoreCLR and it is not feasible to update it to do so). Within ASP.NET 5 our primary focus is on SQL Server, and then PostgreSQL to support the standard Mac/Linux environment.
Because ASP.NET 5 applications can also target the full .NET Framework, fulfilling our commitments to ASP.NET 5 will also allow EF7 to be used in other applications that target full .NET (WPF, WinForms, Console, and ASP.NET 4).
After fulfilling our ASP.NET 5 commitments, the other priorities of our team are as follows. These are in no particular order and we will likely work on them in parallel.
- Implement additional features
- Support EF7 on other platforms (Phone, Store, etc.)
- Deliver additional providers that our team will own (SQLite, Azure Table Storage, etc.)
What does this mean?
Scoping functionality for ASP.NET 5 release
To meet the dates for the initial release of ASP.NET 5 we are going to have to scope the functionality of EF7 to exclude some features that we would consider basic O/RM functionality. Examples of this include lazy loading and inheritance mapping patterns.
Because of this, we won’t be pushing EF7 as the ‘go-to release’ for all platforms at the time of initial ASP.NET 5 release. More details on this later in the post.
Temporary removal of providers from working branch
In order to focus on our top priorities we are going to move several providers to a separate branch that we will not always keep updated with the latest changes. The packages will also not be published as part of nightly builds or pre-releases to NuGet.org. The impacted providers are SQLite, Azure Table Storage, and Redis. This will allow us to iterate on the core framework without the overhead of keeping multiple providers and their tests up-to-date as we go through various interim stages of the core framework.
Once we have stabilized the core and the code churn reduces, we will bring back the additional providers to validate the core framework again and begin working towards an initial release of these providers.
One important implication is that the SQLite provider will temporarily not be kept up-to-date or published in our nightly builds. This temporarily removes the ability to target Phone/Store applications during this period.
Tasks we’ll be working on
Scoping features and removing some providers will allow us to focus on the following activities for the initial ASP.NET 5 release.
- Complete in-flight features
- Fix bugs
- Add test coverage
- Test and improve performance
- API reviews
- Exploratory Testing
- Clear exceptions for unsupported scenarios
- Documentation
- Add logging throughout stack
Initial release for ASP.NET 5 != recommended release
As previously mentioned, we won’t be pushing EF7 as the ‘go-to release’ for all platforms at the time of the initial release to support ASP.NET 5. EF7 will be the default data stack for ASP.NET 5 applications, but we will not recommend it as an alternative to EF6 in other applications until we have more functionality implemented.
Given that ASP.NET 5 is in the same ‘part v1 and part vNext’ position as EF, the missing features will be less of an issue. We will of course be working to make them available ASAP.
We are discussing ways to make this clearer when it comes time to ship a stable version of the EntityFramework package to support ASP.NET 5. We haven’t locked on the details yet (and won’t until we get closer to release) but some options we are considering are:
- Still have the NuGet package marked as pre-release so that it is not installed when you ask for the latest stable version.
- Only support the ASP.NET 5 platforms so that it is not inadvertently installed in other applications. In this scenario you could still install a pre-release package for use on other platforms.
Summary
To ensure we meet our primary commitments to ASP.NET 5 we are going to be focusing on rounding out the existing features and the SQL Server provider for EF7.
This means scoping out some very important features and we will not be encouraging folks to transition from EF6 to EF7 until these features are added.
We will temporarily be suspending work on SQLite, Azure Table Storage, and Redis providers and they will not be included in nightly builds. These are important scenarios for us and we will re-enable them as soon as we meet our ASP.NET 5 commitments.
We understand this is disappointing to many folks. Most notably, temporarily disabling Phone/Store was a painful decision for us to make. Our team would love to work in isolation and make EF7 a complete and polished product on many providers and platforms before initial release. Unfortunately that is not the case, so we’re working to meet our commitments while still delivering on the all up vision in a reasonable time frame.
Comments
Anonymous
December 02, 2014
The comment has been removedAnonymous
December 02, 2014
As you said you can always turn off lazy loading in EF6, so I don't see the issue. Personally I find lazy loading very useful in specific scenarios. I hope you never consider not adding lazy loading at all.Anonymous
December 02, 2014
> Because ASP.NET 5 allows apps to target CoreCLR, the existing EF6.x product cannot provide this functionality (as it does not run on CoreCLR and it is not feasible to update it to do so) Is there information available what made EF6 not being able to run on CoreCLR? I understand the System.Data.* namespaces still have to be ported to CoreCLR, but that this is done before RTM, however what else is broken that makes EF6 not run on CoreCLR is perhaps also important to know for other frameworks which target e.g. System.Data.* and are looking to run on CoreCLR. TIAAnonymous
December 02, 2014
I hate to ask, because I am assuming, but will EF7 be compatible with Xamarin.Forms?Anonymous
December 02, 2014
@Frans Bouma System.Data contains Odbc and OleDb providers in addition to Sql Server provides, it has references to System.EnterpriseServices which is a giant COM wrapper over windows specific enterprisey COM+ objects (don't even know what they do), then there's DataTables and DataSets and that implement IBindingList, IBindingListView and other legacy System.ComponentModel interfaces from the .Net 1.0 WinForms era. I don't think I even like the idea of Microsoft porting System.Data to CoreCLR.Anonymous
December 03, 2014
@Catalin Pop Sever: Actually, async lazy loading support might not be a bad idea. Force all lazy-loadable properties to be virtual Task and await them every time, whether they have been cached or not. Might seem "ugly" for a POCO, though. Possibly better idea: IObservable and then use Rx everywhere for "lazy loading". Theoretically, you could even leverage IQbservable and get some SQL Provider query optimization smarts in play even in "lazy loaded" scenarios...Anonymous
December 03, 2014
Yes, that's what the world needs... more async zombie code. :PAnonymous
December 03, 2014
Can we see some dynamic typed code first pretty please?Anonymous
December 03, 2014
This post is largely event based, in the sense that you will first work ASP.NET5 and then other priorities such as Windows Phone. Since there are no times associated with these "events" it is difficult to gauge the impact of delays in working the Windows Phone implementation. Can you provide even a sketchy sense of timing on all of this? Absent this information, I am left guessing as to what to do about a planned Windows Phone development effort. I understand you can't make promises or even lay out a real schedule.Anonymous
December 03, 2014
I really like this new direction you guys are going. Looking forward to seeing the final results!Anonymous
December 03, 2014
It would be great to have a general roadmap overlapped with the schematic with the .NET, ASP and EF versions are we are planning to have out there. Probably start with .NET 3.5, EF 3.5 and ASP MVC 2.Anonymous
December 03, 2014
Is the list of cuts in this article complete? I'm a TOP 250 Stack Overflow user. I see a lot of stuff that people actually do and use with/in EF. If you ask me what data stores they will use: 98% SQL Server only. If you have to drop something to meet a schedule - delay doing all the data stores except SQL Server. Make the ORM "nice". This involves getting the basics right. One of the basics is Lazy Loading. Inheritance is something that can be delayed rather easily, yes. 98% of the time people just want a simple, predictable ORM. I myself want that as well.Anonymous
December 04, 2014
Q1: What percentage of EF users are targeting MS SQL Server platforms? Q2: What percentage of EF users are targeting major SQL platforms (MS, Oracle, Sybase, IBM)? It's important to us that SQL Server be #1 target for EF and EF be as free of COM as possible.Anonymous
December 04, 2014
Based on all of this, I really think you guys need to consider giving it a new name. It makes no sense to call it "Entity Framework 7" but you can't upgrade from EF6 for most scenarios. For starters, that would be a NuGet nightmare. In more ways than it is a step forward, it is a huge step backwards for existing users. It's a huge step backwards from even what you were thinking about shipping. Call it ObjectSpaces or Lightweight Data or DataLite or something, give it a V1, and let's stick a fork in EF. Because, at this point, I think it would be really hard to call what you're shipping next a V7 of anything. You guys just said yourselves it will barely even be a V1. Just my $0.02.Anonymous
December 04, 2014
What is the f#cking rush for EF7 or ASP.NET 5 and MVC 6?? Why not spend the time to do it right and at least provide the same basic functionality as EF6 and ASP.NET MVC 5? "Here is some new bits that doesn't do what the old bits do, but it may run faster (we don't release benchmarks officially) and you can now run it on a Mac (which no one will, nor do we want them to because we sell Windows)"Anonymous
December 04, 2014
@Catalin Pop Sever (cc @J. Portelli) – Lazy loading is always one of those polarizing features that folks either love or hate. We’ll add it, but you will never be forced to use it. We may also consider having it off by default in EF7 – thought we haven’t discussed that at length yet.Anonymous
December 04, 2014
@Max Battcher (cc @Catalin Pop Sever) – We have actually considered Task<T> navigation properties to enable async lazy loading… not sure if/when we’ll add it but it seems like a reasonable idea.Anonymous
December 04, 2014
@Frans Bouma (cc @Catalin Pop Sever) – We’ve discussed offline, but for the sake of folks reading the comments… The biggest blocker for us with EF6.x was dynamic type generation (which we use extensively). In EF7 we are looking at using Roslyn at compile time to replace dynamic proxy generation etc. Aside from that, there are just different APIs in CoreCLR and it takes time to go thru and adjust to fit the new APIs (and account for subtle changes in behavior). The subtle changes in behavior were also a big issue for us as those changes can have flow on effects that are difficult to understand in our poorly factored EF6 code base. There is a System.Data.Common package that includes the provider model from System.Data and it works on all platforms including CoreCLR. There is also a System.Data.SqlClient package which is the SQL Server implementation of this contract. BTW on full .NET they both type forward to the existing DbConnection/SqlConnection etc. so you can just rely on the package for all platforms without having to cross compile (this is what we do in EF7). EF7 is also open source, so you could take a look at how we are making use of all this stuff - github.com/.../EntityFrameworkAnonymous
December 04, 2014
@MichaelD! – Using EF7 in Xamarin apps is where we are headed with EF7… but it doesn’t work yet (and most likely won’t work until after the initial release due to work required outside of EF itself).Anonymous
December 04, 2014
@Lambros Vasiliou – Could you elaborate on the dynamic scenario you want to see? Feel free to open a GitHub issue with details and we can track/discuss there.Anonymous
December 04, 2014
@TTRoadHog – We’re planning to have a stable code base ready early-mid 2015 that would then be used to support ASP.NET 5 when they are ready to release. Given our current backlog, pace, etc. we think we’d then have a much more rounded out product that we would recommend folks use in general around the end of 2015 (I’m just giving you our current thinking and things could of course change).Anonymous
December 04, 2014
@Christiaan Rakowski – Thanks, glad things sound good to you.Anonymous
December 04, 2014
@JW – We’re still ironing out some of those details. For example, in the current code base the core of EF7 requires .NET 4.5 and the relational providers require 4.5.1 but we still have some technical things to work though before we decide on our final requirements. We’ll definitely post details once we lock on those things.Anonymous
December 04, 2014
For the sake of NuGet and Google/Bing alone, PLEASE rename this package to something that will keep the EntityFramework 4.3 questions and NuGet update nightmares away. Please.Anonymous
December 04, 2014
The comment has been removedAnonymous
December 05, 2014
The comment has been removedAnonymous
December 05, 2014
@Robert McLaws – Regarding the NuGet confusion, we aren’t going to have ‘Install-Package EntityFramework’ or ‘Update-Package EntityFramework’ give you EF7 in non-ASP.NET 5 apps until EF7 is a good alternative to EF6.x. We listed some of the ways me might achieve this in the “Initial release for ASP.NET 5 != recommended release” section of this post. In our dev branch we’ve also just swapped EntityFramework to be a meta-package that pulls in a few pieces… so not publishing that meta-package is another option.Anonymous
December 05, 2014
@Marc Brooks – I hear you, there will definitely be some confusion. Unfortunately there isn’t a good solution that avoids confusion. Assuming we did rename it to FrameworkXYZ, then you’ll find a whole bunch of existing content that says the current data access stack for .NET is Entity Framework instead of FrameworkXYZ. If you searched for “DbContext” then you’d have to work out if that is the one from Entity Framework or FrameworkXYZ. Our hope is that in the long term sticking with EF7 will have less confusion… but realize that over the next 12 months or so there will be a lot of room for confusion that we need to address as best we can. Not perfect by any means… just wanted to share some of our reasoning.Anonymous
December 05, 2014
@Lorenzo 75 – Brining Phone/Store back into the working code base will likely be one of the first things we do after getting things stabilized… but yes, around 12 months to a stable release is probably correct (that’s not a commitment to any particular dates though). We’ll only prioritize Mac/Linux in terms of support for ASP.NET 5 (which also targets those platforms).Anonymous
December 05, 2014
>> Our team’s top commitment is to provide a data access stack for ASP.NET 5. Why? >>fulfilling our commitments to ASP.NET 5 will also allow EF7 to be used in other applications that target full .NET (WPF, WinForms, Console, and ASP.NET 4). This makes it feel like the non ASP.NET users are just an afterthought. Kind of "if it works for you great". Am I understanding this right?Anonymous
December 05, 2014
@Stephen - Not at all, all the platforms are important to us. We just have partner teams with certain timelines that we need to support and that means we deliver some capabilities before we deliver others. ">>fulfilling our commitments to ASP.NET 5 will also allow EF7 to be used in other applications that target full .NET (WPF, WinForms, Console, and ASP.NET 4). This makes it feel like the non ASP.NET users are just an afterthought. Kind of "if it works for you great". Am I understanding this right?" I was contrasting this with Phone/Store (which won't just work as a result of supporting ASP.NET 5) as opposed to saying Full .NET is a side thought. Even though it will work for Full .NET if you want to use it, we would recommend using EF6.x until EF7 has better feature parity with EF6.Anonymous
December 06, 2014
Not quite sure I understand what you're saying. EF7 will be the default data stack for ASP.Net 5, but it will be marked as prerelease and not installed by default? What? ;) If it doesn't support lazy loading and inheritance mapping, including it as the default will only be confusing. Please reconsider this...Anonymous
December 07, 2014
Hi Rowan, Synchronize MS teams is always difficult and have already doomed some projects, good luck keeping EF on the track! Otherwize, for the Lazy Loading part, I think desactivate it by default is mandatory if you not release it in the first EFvNext release. We don't want to have this kick-in as part of an update... And it will not be this bad as most of EF usecases don't need it. For the version name, why not doing like Windows, and skip the versioning to EF10? You have already do that in the past (V2=>V4) and I think it's a good solution for the present problem.Anonymous
December 08, 2014
So, I've put some trust into emerging EF7 and included it for SQLite on Store/Phone app... Now I read that 'This temporarily removes the ability to target Phone/Store applications during this period.' There is nothing more permanent than temporary So what do I do now? Cut whole EF7 code from my apps, integrate back SQLite-net and learn to live with critical stability bugs in it? We don't need EF7+SQlite on Windows RT in some abstract future. We need it now.Anonymous
December 08, 2014
To those above who are worried about some feature support, it is worth remembering that EF7 is all code, no xml. We should be able to just change code if needed.Anonymous
December 09, 2014
I agree with @Sergey. Maybe Microsoft ought to stop trying to do things on the cheap and elevate EF to a product that has to be purchased. Would that help provide the additional resources to guarantee that the Windows Phone version of EF 7 be moved up in priority? I would be willing to pay for the EF 7 library product. There, I said it. As it stands now, this seems to be one more nail in the coffin of Windows Phone... I'm not too happy this situation. A year is just too long to wait.Anonymous
December 10, 2014
@Henning Kilset – ASP.NET 5 is in the same boat as EF7 where it is part vNext and part v1 and doesn’t necessarily have feature parity with previous versions. For folks who chose to adopt ASP.NET 5 in its early releases, EF7 will be in a consistent state with the rest of the stack (stable, but not everything will be there). We’ll decide on the technical aspects of NuGet packages when we get closer to release, but NuGet supports having different package versions that target different platforms. Versions that only support ASP.NET 5 (aspnet50 and aspnetcore50 platforms) are filtered out when targeting other platforms. So that would allow us to only have the EF7 package installed on other platforms when you specify you are ok with pre-release packages, or explicitly ask for the 7.0.0 version, etc. As I mentioned though, we won’t close on exact details until we get closer to release and know exactly where we are at with EF7 and ASP.NET 5.Anonymous
December 10, 2014
@Bejarid – We did actually consider skipping to a higher version (8, or 10, etc.), but honestly I’m not sure that really helps communicate the scope of changes too much (maybe to some folks, but I don’t think it helps that much in general).Anonymous
December 10, 2014
@Sergey – It’s definitely temporary, Phone/Store is a huge part of our EF7 vision and only comes second in scheduling because of our commitments to partner teams and their ship dates. The Beta 1 packages are still up on NuGet.org, so you can always use those, we just won’t be fixing bugs etc. for the moment.Anonymous
December 10, 2014
@Sergey @TTRoadHog – A year from now is about the time we’d need to get to a stable release of EF7 that supports all the platforms and stores anyway. We’re organizing our work so that we can do the scoped down ASP.NET release earlier. But if our team operated in a vacuum and could just deliver an all up stable release for EF7 when we wanted, it would be around 12 months from now.Anonymous
December 10, 2014
@Rowan Miller, I do understand all of these reasons, but it doesn't solve my issue. I believe I can help with EF7 for SQLite and Windows RT. There are few ways of doing it. Please get in touch with me via sergey@galich.ca so we can figure out how to keep SQLite available.Anonymous
December 10, 2014
So this was me, a few days ago - twitter.com/.../541818488164458496 - celebrating EF for Azure Table Storage. I am building an app where using TS would be ideal. Looking through the comments, no one seemed to raise the issue of pausing on that, but I'm here saying, at least one of us on the EF 7 for TS is disappointed, too. I'll go back to hacking around to make it work.Anonymous
December 11, 2014
>A year from now it is too late, nobody will let me wait that much. I am forced to switch from working prototype on win8 to android >So what do I do now? Cut whole EF7 code from my apps, integrate back SQLite-net and learn to live with critical stability bugs in it? make one more logical step futher - w/o ef7 you have to revert back to sqlite-net with probably some orm on top of it. all of that stuff is ported from java world and there is little reason (c# probably is the last one, but java is quickly catching up) to stay on microsoft stackAnonymous
December 11, 2014
@Sergey – I’ll send you an email shortly and we can follow up there.Anonymous
December 11, 2014
@dbis01 – Just to be clear, we’re talking around 12 months to a stable release. The SQLite provider (and phone platform support) will come back into our working code base and nightly builds well before then. In the meantime, the beta 1 release is up in NuGet.org and you can continue to use it if the limitations are acceptable.Anonymous
December 11, 2014
@Irwin – Comments about SQLite in above comment apply to ATS too, we’ll bring it back into our code base and nightly builds soon enough… and the beta 1 release is there on NuGet.org if that was working for you.Anonymous
December 11, 2014
beta1 is not usable with sqlite. a lot of issues like .Include wierd behaviour, FK creation, etc. >nightly builds soon enough… how soon is "soon enough"? jan2015?Anonymous
December 11, 2014
The comment has been removedAnonymous
December 12, 2014
@dbis01 - Possibly a little later than Jan, but we think it will be early next year.Anonymous
December 12, 2014
@Michal - We're tracking that here - github.com/.../333. On the list for initial release (top priority).Anonymous
December 16, 2014
The comment has been removedAnonymous
December 17, 2014
@Jon: I am not sure about what limitation Telerik is referring to. With the built-in data-bound controls you can simply set the SortExpression of the BoundField to "Customer.Name" and the EntityDataSource will build the right query to sort. By the way, we have no plans to support EntityDataSource with EF7.Anonymous
December 18, 2014
@Diego The problem with regard to sorting occurs when you are using model binding using SelectMethod and not EntityDataSource. This is what I would prefer to use. Defining queries in markup always seemed like a bad idea to me. I would much rather do it in code. However, right now, I'm using EntityDataSource. I want to switch off of that since as you mentioned, I figured Microsoft would be dropping support for EntityDataSource. One other thing that I remembered after I last posted was that if you use a SelectMethod with RadGrid that returns an IQueryable, it doesn't run the filters in the database like I think it does with a Microsoft Grid. It loads it into memory and then does the filter. I think that's a Telerik limitation. Web Forms in general seems to not be a priority for Microsoft at all and hasn't been for awhile. Web Forms is a better for LOB applications IMHO. MVC is overrated IMHO.Anonymous
January 09, 2015
The comment has been removedAnonymous
January 09, 2015
@DickInKent - Yep, database => model is definitely a key scenario for EF. It is one that has traditionally been less polished with EF, in particular with Code First. We ideas on how to improve it, but some of them are going to take us a couple of releases to land. Agreed, sticking with EF6.x until EF7 is baked is a perfectly valid option - and what we would encourage folks to do.Anonymous
January 14, 2015
Hi Rowan I'm trying some tests, but it's very dificult since I use a legacy database with table and column name different to those used on the entities, and the configurations for mappings are far different than those of EF6 (I think something is even absent) Can your team provide a documentation of what is different and how it's done on EF7, and what is not yet implemented? ThanksAnonymous
January 15, 2015
@Fernando - EF7 is still very much pre-release and things are still churning quite a bit. Because of this, we aren't really writing documentation yet since anything we write goes out of date within weeks (or even days). We are turning our attention to stabilizing things now though and are starting on API reviews etc. so I think we'll start some documentation in the coming months. In the meantime, things are generally where they used to be but if you want something that is specific to relational database (table name etc.) then you usually want an AsRelational() method call and then you'll get what you are after. We have some very basic docs here - github.com/.../Using-EF7-in-Traditional-.NET-Applications.Anonymous
January 26, 2015
For the currrent prelease, .NET 4.5.1 is required: "To use a relational database provider, your application will need to target .NET 4.5.1.". Will this be the same deal for the full release? Will there ever be a possibility to run EF7 on .NET 4.0? Taking into account the modular setup of the new framework, I'd find it strange that the .NET environment would be more restrictive than its previous version.Anonymous
January 27, 2015
@Bart - 4.5.1 will be required. EF7 is dependent on some API changes that were not present in 4.5.Anonymous
February 04, 2015
The "release" branches of Asp.net vnext includ " EntityFramework.AzureTableStorage"provider,Can I try it now?and how? www.myget.org/.../aspnetreleaseAnonymous
February 05, 2015
@Lee - Azure Table Storage was included in Beta1 of EF7, so there is an early build you can try out (it was published to NuGet.org). It won't work with the later builds of EF7 or ASP.NET 5 and we also won't be providing any assistance/docs/etc. until we resume active development. You can find an example of the Beta1 package being used here though github.com/.../demo-EF7.Anonymous
February 17, 2015
I require lazy loading be disabled in our apps so no problems there; however, the lack of inheritance mapping on inital release is disappointing. Still, I'm very pleased with the direction you are taking EF7.Anonymous
March 03, 2015
I have heard that EF7 won't include any GUI to provide a visual representation of the design. Please tell me that this has at least partially been reconsidered. Even something that starts as read-only would be helpful. I am not suggesting to keep the xml description info that was decided to be removed due to dropping "database first", but to instead build the GUI based on the classes that were created. It could be something like a "Class Diagram" but specifically for EF7 (An EF Class Diagram perhaps??) :)Anonymous
March 10, 2015
The comment has been removedAnonymous
March 13, 2015
@José Luís - Here is some documentation on using EF with WinForms msdn.microsoft.com/.../jj682076. If you have specific questions beyond what is covered there, it would be best to ask them on StackOverflow.com (be sure to use the entity-framework tag).Anonymous
March 13, 2015
@Dr. Zaius - Lazy loading is definitely a 'love it' or 'hate it' feature. There seems to be about a 50/50 split on whether it should be enabled or disabled by default. Good news is that we've already started implementation on inheritance support earlier than we expected to get to it.Anonymous
March 13, 2015
@Mark - We definitely agree there is value in a visual view of a model. I don't have any particular dates etc. on when it would be available, but one of our team members has already done an rough prototype of a simple view of EF7 models.Anonymous
March 14, 2015
The comment has been removedAnonymous
March 16, 2015
@Gerardo Recinto - Open up an issue on our GitHub project and we can discuss there github.com/.../EntityFrameworkAnonymous
March 20, 2015
Hello Rowan, It's been a little over a month since your last comment regarding the delay on the work getting Azure Table Storage into EF7 in order to concentrate the team's effort for the release of ASP.NET 5. Can you provide an update on where things are at with ATS? I have a very large app with a great deal of ATS CRUD operations that's in need of ATS in EF7. I guess specifically it would be helpful for my planning to know at what point can we look for in the release of EF7 and/or ASP.NET 5 as a signal that you will be getting back to ATS in EF7 and can you make a wild guess as to when this might happen ... I mean is it more like a "a few months" or more like "it could be a year?" One final ?: Regarding the ATS in EF7/Beta1 (per Demo-EF7 that you referenced above) ... To your knowledge, how stable is that ATS code AFAIK? Could I use that safely in production right now? I would only need the ATS parts of Beta1 to work. Thanks!Anonymous
March 21, 2015
@Rowan - thanks for the info, 'just created a new issue, link: github.com/.../1879 Awesome.Anonymous
May 12, 2015
@Luke Latham – We’ve pulled SQLite back into our working code base but ATS is still a little ways off. I don’t have a timeframe for pulling it back in but it probably won’t be in the next couple of months. I would say the Beta1 code base is fairly stable for simple scenarios. I wouldn’t really recommend it for a production app… but if you test it and it works then we won’t stop you :).Anonymous
May 24, 2015
I don't know why people don't simply continue to use EF6 while EF7 is on its way instead of complaining. If a new library is released, I'll play with it on side projects a couple of months before even considering it for "real" projects. The objective is to have the time to figure out all the gotchas etc... to avoid beeing stressed and upset whenever something goes wrong. In the meantime there are stable libraries out there that I can continue to use as I've always done. I have one question, is EF7 going to backward compatible ? I mean, if I'm using EF6, is the upgrade to EF7 going to be smooth or do I have to plan for changes in my codebase ? Also, I just wanted to make the voice of DDD practitioners heard to say that lazy loading is really of the essence for us. By definition, you don't want the client to think of - or even understand - what's being done in the encapsulated model, therefore eager loading is very marginal and only used sporadically for performance tweaks. I think DDD is a big scenario, so lazy loading is really of the essence. Same statement for inheritance. I'm very VERY excited by the announcement about proxies being generated at the compile time with roslyn instead of dynamically, it sounds like the performance gain will be massive. DbContext is known to become exponentially slower as the number of tracked objects increases but there are times when lots of computation needs to be done in one unit of work and lots of entities retrieved to support feed them, is there a breaking design change in EF7 - like compile-time proxies - that would address this issue ?Anonymous
October 19, 2015
@r2dnb – No, EF7 is not backwards compatible with EF6. We are trying to minimize the code changes required so that you only have to change your code when the way EF works has fundamentally changed (i.e. if there is a method in EF7 that does the same thing as a method in EF6, then we call it the same thing). EF6 to EF7 should be viewed as a port rather than an upgrade.