This sounds a bit silly but I am uncertain of what it is I am actually using when I think of "Entity Framework". I noticed that when searching for documentation, I often end up with object and methods that I simply do not have or use directly (such as objectcontext, EntityState, ect). I'm also unsure of which Linq I'm using at any given time (Linq2SQL, Linq2Entities, Linq2Objects).
What I think I'm using:
Database-first ADO.NET Entity Data Model and Linq to Entities.
My setup:
Microsoft Visual Studio Professional 2015, installed with default settings using the installer downloaded from the official website. Up to date, no additional addons, library or packaged installed.
What I do:
Design a database like this and create it in SQL Server
MyFooDB
table Foo ( PK int Id, varchar Name)
table Bar ( PK int Id, bit Active, FK int FooId references Foo.Id )
Open VS2015, File > New > Project > C# > Windows >Console Application.
In the solution explorer, right-click the project node > add > new item > Data > ADO.NET Entity data model.
A dialog opens, I choose EF designer from Database, connect to my server and choose my database "MyFooDB". At the bottom of the dialog it says that the setting will be saved in the app.config as "MyFooDBEntities".
I get asked which version of Entity Framework I want to use, this time I'll choose 6.X .
A dialog appears for me to choose which database objects I want to include. The model namespace text field says "MyFooDBModel". I check "Foo" and "Bar" then click Finish.
An edmx file is created and opened. I see a diagram of the objects I chose. Under the edmx file I see this structure:
MyFooDBModel.edmx
-MyFooDBModel.Context.tt
-MyFooDBModel.Context.cs
-MyFooDBModel.Designer.cs
-MyFooDBModel.edmx.diagram
-MyFooDBModel.tt
-Foo.cs
-Bar.cs
In Program.cs, I instanciate a MyFooDBEntities and use it:
var db = new MyFooDBEntities();
var firstFoo = db.Foos.First(x => x.Id == 1);
if (!firstFoo.Bars.Any())
{
Bar b = new Bar() { Id = 3, Active=true };
firstFoo.Bars.Add(b);
db.SaveChanges();
}
And so my question is what are the different technologies I used and how do they relate to each other?
LINQ2SQL is a completely different (and no longer supported) technology, it used to have different templates and was sort of the "quicker and simpler" version of EF (although there was no actual relationship between the two).
LINQ2Objects is the description of applying LINQ expressions to objects/instances in memory, not really the sames as either EF or L2S.
You are indeed using Entity Framework, along with the Entity Data Models (EDMX). EDMX is a carry-over from older versions of EF where you had a design surface (remember when those were cool) for designing your data model. With EF6.x, you can still use these and they are essentially used to generate .cs files for you. This is no longer what most people would consider to be the "Best Practice" for using EF, the preferred way of generating your model now is using Code First and POCOs.
Under the hood, EF 6.x still has a lot of legacy dependency on the EDMX paradigm and so the code first and fluent configurations are used to build this up to some extent, so I don't think there is any significant functional differences between the two. But generally speaking code first is much easier to work with, maintain, and for 3rd parties to understand your code.
With Entity Framework Core (formerly Entity Framework 7), it's been completely re-written and the EDMX models are no longer supported, so for that reason alone you might consider ditching them (not sure if or what the migration path is between 6 and Core).
Related
We're just starting to move off of a legacy codebase and begin using .net and Entity Framework Core for most of our new software.
We've migrated our database from our old platform to SQL Server, but the data is old and poorly normalised. We cannot undertake a normalisation project all at once because of the potential impact on the (large) existing codebase in the legacy language, so we are adding primary and foreign key definitions to our database as we go, and regenerating our Entity Framework Core model from scratch as more tables become valid for the framework.
I feel like we're missing some important capabilities of Entity Framework Core by doing this, but I don't really know enough about the framework to identify what it is. I know the generated model lacks completeness (my question was prompted because a table with an Identity column did not have the column marked as ValueGeneratedOnAdd(); in fact that table does not appear in the OnModelCreating method at all) but I don't know whether that's an issue with the database or another mistake I'm making.
My question is: what capabilities are there within Entity Framework Core to manage a rapidly-evolving database model? What should I be doing for myself, and what should I be relying on the Scaffold-DBContext command for?
With EF Core, most of the things you will need will be done by Scaffold-DBContext. The only things it doesn't handle right now is DBQuery sets. You will have to manually code those. Other than that, everything else is handled pretty eloquently by the command.
As far as ValueGeneratedOnAdd(), the only time I have ever seen this as a problem has been Versioned tables. If you have a versioned table, Scaffold-DBContext will not add that to those fields and you must have those so you will have to manually add those to your code.
Why when I saving the EDMX file in VS2012, hi always change the attributes of the component classes?
I use a marker there [NotMapped] with System.ComponentModel.DataAnnotations.Schema and it is always the same clause and using are removed.
EF does not support Agility methodologies?
1) I want to just make simple calculations on the data and display them in the attributes. For example, the document number is the number and prefix.
2) the model-first and code-first for me is not enough. I create an application based on data from the ERP and I have to add Me own document type. Half of the data is in the database and I can not duplicate it. The other half is my new tables. At the same time I do not know yet where I will use the data and I am not sure what the relationship between them I used. (I can not create a relationship right away in the diagram on the 500 tables). The client does not know yet what the data which depends. Typical thing to Agile methodologies.
Learn and use the code-first approach. It will give you full control over your POCOs (plain old class objects). The model-first approach requires that you use the EDMX modeler to make your changes which does not allow you to do much customization underneath.
Entity Framework Tutorial website is a good resource to get started as is the official Entity Framework website.
We are using Entity Framework 6 with Model-First, which by default results that our entities, the dbcontext, the .tt files, and the model files are crammed in a single folder, without any structure.
I would like to achieve some separation, at least something like this:
Project root/Entities/entities generated from model
Project root/Repository/everything else (.tt, .edmx, etc...)
Is this possible?
It is not. EF is in charge of where it puts stuff and where it expects them to be; you can't change that.
What you could do in order to get a bit closer to what you want is to use EntityFramework Power Tools to reverse engineer the database and produce a set of POCO classes that can be used as your data access.
It's often described as Code-Second I believe.
You can installed the Power Tools and then select the location in your solution where you want the classes to be and then right-click and select "Reverse Engineer Database" {sic}
sure you can! I don't know what do you mean by
Project root/Entities/entities generated from model
Project root/Repository/everything else (.tt, .edmx, etc...)
but you can even separate the assembly. you can have you domain entities, repository and Context class in an assembly or in a namespace.(it's better to do that for make you app maintainable). take a look at this and this blog posts. hope it helps
We have a fairly elaborate data model built from an existing database, then enhanced using partial classes to support additional methods & properties, inheritance, etc. We have not yet bitten the bullet to update this from ObjectContext to DbContext.
I am using VS2012, .net 4.5, EF 6.0.2, and have installed the EF 6.0.2 Tools for VS2012.
Following the recommended mechanism to update a project to EF6 (http://msdn.microsoft.com/en-us/data/dn469466) has been successful, including the addition of the EF 6 Entity Object generator as the code generation item.
Subsequent to making this change, I would like to update the model from the database to incorporate some recent schema changes into the model. Running through the "update model from database" dialog, what appears to be happening is that an entirely new dbcontext-based model & template is added to the project, in addition to the object context-based model that already exists in the project, and none of the changes are incorporated into the entity-object template.
Of course, this means there are hundreds of duplicate names defined in the project once the operation completes. The edmx properties do not appear to have an option that would control this behavior.
Certainly, making the transition to dbcontext is the right avenue ultimately, but would like to avoid taking that on imminently.
My experience is open edmx file in visual studio by double-click and then select all tables perform a full delete(press del). Then click save button on top of menu bar, it should delete all models automatically.
After it's done, then you can update model from database again.
Hope this helps.
I am using .Net Framework 4.0. I have an entity model (.edmx) and I have a menu option in my program for connecting to an existing database or creating a new one. When the user selects to create a new database, I want to generate the database and schema from the entity model. Any idea how to do so?
Don't do it. It will only work on your v1 products and as soon as you'll plan to release v1.1 you'll realize you have no way of upgrading existing deployed databases to the new schema.
Instead, use scripts to create all your objects (including indexes, relations, constraints, everything) and use upgrade scripts to control how to upgrade each schema version to the next version, like described in Version Control and your Database.
A weaker alternative is to have a Visual Studio Database Project in your solution because VSDB projects have upgrade capabilities, although diff based. They allow you to deploy .dbschema files using the vsdbcmd tool and this tool can diff and upgrade an existing schema. You can have the VSDB project output be transformed into the EF model via an build transformation step (is not trivial, but is possible).
Overall, do not fall for the lure of the EF (or Linq) modeling as being the master definition of your schema. You'll pay the bigger price later.
Take a look there : How to: Generate a Database from a Conceptual Model (Entity Data Model Tools)