Edge of the Web: Entity Framework Core: The Future of EF for ASP.NET Core
- Posted: Mar 28, 2016 at 5:59PM
- 5 comments
Have you ever wondered how you could write code that interacts with your database? Well now you can with EF Migrations in the new Entity Framework Core for ASP.NET. Check out the latest from the Edge of the Web series and get ready for an in-depth overview and demo heavy session to learn how.
- [0:30] Entity Framework Core Overview & Demos
Follow the conversation @msdev
Become a Fan @ facebook.com/MSFTDev
Subscribe to our podcast via iTunes, Windows Phone Marketplace or RSS
If you're interested in learning more about the products or solutions discussed in this episode, click on any of the below links for free, in-depth information:
Websites & Blogs:
Comments closed
Comments have been closed since this content was published more than 30 days ago, but if you'd like to continue the conversation, please create a new thread in our Forums, or Contact Us and let us know.
More entries in this blog
-
Developers! Get Involved! Join the Humanitarian…
-
Edge of the Web: Entity Framework Core: The Future…
-
Security Best Practices for Developers
Follow the discussion
Oops, something didn't work.
What does this mean?
Subscriptions allow us send you email notifications when new content is added. You need to be signed in to Channel 9 to use this feature.What does this mean?
Subscriptions allow us send you email notifications when new content is added.sign up for email notifications?
Hi, thanks for the video.
I have a question regarding migrations. In this demo you had all the staff in single project, so when you were generating migrations, the code was added to this project. But what happens if I implement my persistence layer in a separate assembly and want everything related to data access to stay in this assembly (including migrations)? In other words, how do I generate migrations in a project different to Web App project?
@andriysavin: I've done it with separate projects in a real-world application. The location of the models are identified by their namespace (which can be in a referenced assembly from another project) and the migrations can live away from the web project.
In Solution Explorer, the default startup project would typically be your web project. In the Package Manager console, you can define a different default project to run migration commands in.
@shahedC Great, thanks!
Hi Shahed,
thanks for this brilliant tutorial.
With EF7 is it still valid to use Generic Repository and Unit of Work Pattern
Many thanks
Zak
@zaktecs: check out this Q&A on StackExchange that addresses your question in detail:
* http://programmers.stackexchange.com/questions/314266/are-repositories-needed-any-longer-in-asp-net-5-ef7
It references the official ASP .NET Github:
* https://github.com/aspnet/EntityFramework/issues/4899
There's also a mention of a response from Rowam Miller:
* https://github.com/aspnet/EntityFramework/issues/4899#issuecomment-200927141
Rowan says: "It's really up to you. There are two main reasons you may want to introduce a repository which are not handled by DbContext:
* Removing any strong coupling between your app logic and data access layer. Though in reality, even with this abstraction it is very difficult to swap out a data access layer unless you build and test for multiple data access technologies right from the start.
* Constraining the operations that the app layer can perform on the database. DbContext exposes IQueryable so the app can compose any query allowed by LINQ. Repositories that don't return IQueryable can help you control what is sent to the database.
Ultimately it comes down to a philosophical/style/preference decision. Many apps have been built successfully using either approach."
Remove this comment
Remove this thread
Close