I used the EF 5.x DbContext Fluent Generator to generate my POCO classes but my properties are not coded as virtual. Don't you have to have that for tracking to occur? Why wouldn't the template already use virtual for properties?
Because we found that for the majority of users it was better to use snapshot change tracking rather than change tracking proxies. Change tracking proxies have their place in certain situations, but usually they add complexity without any real benefit. For more info see http://blog.oneunicorn.com/2011/11/24/why-are-the-dbcontext-t4-templates-so-different-from-the-ef4-poco-templates/ and http://blog.oneunicorn.com/2011/12/05/should-you-use-entity-framework-change-tracking-proxies/
Related
I am wondering about designing a EF core model of the SAP B1 database. I realize that this is a major undertaking, but I aim to start small.
This is mainly as an exercise, which may lead to something in the future.
My main issue right now, is to ensure that the DbContext is read-only.
I have found several suggestions, like this one:
How to make Entity Framework Data Context Readonly
However, that is for the Entity Framework "standard" not core, and the accepted solution does not seem to be possible with EF Core.
So, aside from using a login without write permissions, how would I go about making a read-only DbContext?
I am using EF Core 5.0.
Some of you may be familiar with the DbContextScope library, which allows you to nest scopes within your code, and allow those scopes to share a common DbContext. The idea is that the DbContext gets managed for you by the scope library, and instead of calling SaveChanges() on the context, you call SaveChanges() on the scope. The magic happens because the scope will only save all the changes on the context at it's outer-most call of SaveChanges(), so all the nested operations performed on the DbContext get saved in a single transaction at the outer scope-level.
Now that DI is a first-class citizen in .NET Core, it appears that scopes have also become an important part of the .NET Core ecosystem, and the EF Core team, knowing this, has implemented scoping based on allowing DbContexts being injected by the DI system, and (I assume) allowing change saving to happen at scope-levels and not directly on the DbContexts in some way.
So my question are these:
What is the appropriate way to share a DbContext via a scope, allowing the SaveChanges() be managed at the scope level and not the code-level that typically calls SaveChanges() on the DbContext?
Are there new mechanisms in EF Core that manage this for you, just like DbContextScope did this for you as a 3rd party library?
Save me the drama, and spare me the lectures on why you think UOW needs to be implemented in addition to EF. K thnxs bye.
UPDATE: As of 6/2020 there are several forks of DbContextScope that work with EF Core 3.
UPDATE: Forks of this project can be viewed here: https://github.com/mehdime/DbContextScope/network
There are several EF Core 3 versions... I haven't tried any yet, but there you go.
Since Entity Framework 5.0.0, there is IDbContextFactory<TDbContext> that lets you control the creation and disposal (!!) of your DbContexts.
Instead of registering your DbContext with AddDbContext or AddDbContextPool, you can now use AddDbContextFactory or AddPooledDbContextFactory, respectively.
Note that this feature takes care of one of the problems that DbContextScope solves, not all of them. As for what the other problems and solutions are, refer to Mehdi's original post. It is long but excellent.
DbContext sharing is built-in to the Dependency Injection design for EF.
The DI container will generate a scoped DbContext instance for each web request. You can share the DbContext instance from any component that has a dependency on it, and call SaveChanges(), or manage transactions in your outer controller.
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.
What is the importance of POCO support in Entity Framework?
Maybe its better to ask What is the uses of POCO ?
Actually POCO is similar to POJO (Plain old java objects) in .net world. POCOs are objects tha don't have to follow any particular conventions (implementing any interface ,extending any class,having special attributes or naming convention etc.)
Some of the persistent frameworks force us to use specific interfaces or attirbutes , abstract classes. This is not a problem as long as you are working on a project from scratch and you are choosing which framework to use but if you are working on a legacy system and want to change its data access layer to use a persistent framework , it might have a negative impact.
Realy short:
That you have objects that didn't know anything about the EntityFramework but are bound to it (Bound to the context so that the EntityFramework can take care).
I am about to start implementing the data access infrastructure of a project that was architected with an approach to DDD (it's my first attempt on DDD, so be gentle ;-) ).
I will be using Entity Framework. Until now, I was looking into the method teached by Julie Lerman on her great book, Programming Entity Framework, where ADO.NET POCO Entity Generator is used, with some changes to the T4 templates and some more custom code.
Today I started reading articles on EF4.1 and the ADO.NET DbContext Generator, using Database First approach, and I'm trying to decide with which one should I go.
DbContext and EF4.1's approach on DDD seems to be a nice, cleaner way than POCO Entities, but I'm afraid that it could lead to some issues in the near future, since EF4.1 is still in RC.
From ADO.NET team blog, I know that EF4.1 does not include:
Enum support
Spatial data type support
Stored Procedure support in Code First
Migration support in Code First
Customizable conventions in Code First
From my understanding, since I will be using Database First there is a smaller number of features that were not included.
In conclusion, my question is:
Can I replace POCO Entities Generator with EF4.1 DbContext Generator?
From a point of view of clean creation of POCO entities, there is no difference between the two generators. Both generators produce the same entities, however, ADO.NET POCO Entity Generator is based on ObjectContext's API, whereas ADO.NET DbContext Generator is based on DbContext's API.
DbContext's API has a few very nice new features (Local, Query on navigation property, etc.) and API is somehow simplified but at the same time it looks like some features used in ObjectContext API are missing in DbContext API (or at least it has not been explored enough yet).
EF 4.1 RC is go-live release. It means that you can build a real application with it because API will not change in RTW (only bugs will be fixed). Also RTW should be in the next month so I think you will not be ready with your application before the final version is shipped.
ObjectContext API or DbContext API? ObjectContext API is much better covered by documentation and blog posts. You can find plenty of examples about it. Also its limitations are already well known. DbContext API is new release. A very promising release, mostly because of the code-first approach. There is still a very limited number of blog posts, no book and the API is not proven enough. So it depends if you are ready to fight with new API? If not, then ObjectContext API is still a good choice because you don't need the code-first approach.