This question already has answers here:
Closed 11 years ago.
Possible Duplicate:
EF 4.1 Code-first vs Model/Database-first
i made some research, but answers did not satisfy me.
I started my own asp.net mvc application with entity framework, to work with database. I started by making a db, than i create model from that database. Well i know thats called "model-first". I know the second way, of doing it from school (code first). My lecturer told me today, that model-first method is rly outdated. Well is that true? Or maybe: does code-first have any advantage? Whats the real difference, which one is better, in your opinion?
Specifically with EF code first refers to the code and model first refers to the database.
which is better really depends on the project. If the db is treated as the core of the application, or you are using db specific features, than a model first approach makes sense.
If the domain model is treated as the core of the application, leaving the db to be just a form of persistent storage, than a code first approach is practical.
as a side note: this concept is usually referred to as model first (the domain/code) and db first (the db schema). with EF this is somewhat confusing as model refers to the db schema, not the domain model and code refers to the code.
DB first is not outdated at all. In fact, for many corporate projects that's the way to go.
If you are building something for yourself from scratch, code first will probably be a better approach.
Entity Framework provides: 1)Database first, 2)Model first and 3) Code first.
1 & 2 Creates the edmx file
Database first: Entity Data Model(edmx:StorageModels) is created from an existing database.
Model first: Conceptual Data Model(edmx:ConceptualModels) is created with designer and mappings specified. Database will be generated from this.
Code first: Create your .NET classes(no .edmx file). Database will be generated from this.
'Old school' would be using ADO.NET DataSet/DataTable.
Fastest data access is using DataReader and writing your own data access.
No framework will be faster than using a DataReader to populate your own POCOs.
Related
I have a new MVC website (Internet Application) created using VS 2013.
I come from a Database first background and would like to take this approach for this project.
The project from what i see already has Entity Framework installed but i don't see any Entity Data Model files most likely because the project is Code First by default.
How could i bring the Database First approach in this project (the tables are already created within the database)?
Adopt the "Code First to an Existing Database" workflow, which is really a database-first workflow.
That will allow you to add a generated DbContext that maps to your existing database, without introducing an .EDMX file and the old designer-based database-first workflow.
The old EDMX-based database-first workflow should not be used for new work if you can help it. There's a lot of obsolete design and complexity in the OSpace/CSpace/SSpace mapping that Code-First hides from you, and EF Core has eliminiated entirely. There's some functionality in EDMX that hasn't been replicated in code-first, but there are reasonable workarounds for most of it.
I have used Entity Framework code first with good results.
The project uses a second, legacy database which is already designed and running.
I'd like to call both databases in the project. Does any one have any suggestions of the best solution to do this?
I have done both seperatly (in tutorials) but never both. Yes its not the best idea to connect to two databases but each database has distinctly different datasets.
I am already using EF Code first and have been using POCO classes. Would you suggest creating a EDMX file as well? Assume would need two db context files?
I have done several solutions where there was a Code First connection and a Database First connection used in the same project without any issues. I would do as you stated, just create the edmx for the existing database.
I generally create one library project for each database and reference them from the main app project, just to help keep things from getting mixed up.
You just instantiate a context for each database and use them just as you would with a single context. They act as completely separate, independent repositories.
I have a MVC project that use Entity Framework 6. I am puzzled as how it is created. Because there is no .edmx file, I guess it must be created as EF 6.x dbcontext generator. So what does dbcontext generator do? Does it create database from the model? If so, how to create database in the model? May I modify the database later and update the model? What are changed in the sources? Thanks.
It's difficult to understand everything you're saying, but it sounds like you have a project which uses the "Code First" approach. There is no .edmx file in this approach. Entity Framework Code First can be used with both new (see: https://msdn.microsoft.com/en-us/data/jj193542.aspx) and existing databases (see: https://msdn.microsoft.com/en-us/library/jj200620.aspx) and with regards to updating it, you could either manually modify the database or you could look into something called "Code First Migrations" (see: https://msdn.microsoft.com/en-us/data/jj591621.aspx), which allows you to add/remove tables and fields via code.
As far as I can tell (correct me if I'm wrong), there are two main approaches to using Entity Framework:
Model First: start with a predefined database and let EF create the code for you.
Code First: write the code, and let EF create the database for you.
I have an existing database and I'd like to write the code myself. Is this "Code Only" approach supported? Does such an approach even make sense in the context of EF?
I disagree with most of the other answers. From what I've seen, the EF "Code First" technology is really just a way to define your model using conventions, annotations, or a fluent mapping definition, rather than an EDMX file. If you write your "Code First" files to mirror your database schema, there is no reason that Entity Framework would be unable to produce the appropriate queries and statements using LINQ to Entities.
For more information, see Scott Guthrie's post on Using EF "Code First" with an existing database.
Entity Framework Power Tools allows you to reverse engineer a database to generate code first like code (that won't re-generate your database). Then you can tweak it from there as you need.
I believe you have to decide what your system of reference is -- the code (Code First) or the database (Model First). If you have an existing database, then go with a Code First approach, it will be hard to keep your changes in synch without generating your model from your code, or your code from your model.
If you have an existing database, but want to extend your model beyond the generated code, you could implement partial classes to accomplish this.
If you want to manually map your EF4 code and your database, you could consider this approach. However, this eliminates some of the benefit of an ORM, which is to set up the mapping for you.
Well I guess you can't have your cake and eat it too in this case - there has to be one definite source on what your model is, it is either the database (DB first), which then generates matching code for you, or the code (Code first) which will then create a matching DB.
The Entity Framework team answered these questions on their blog:
http://blogs.msdn.com/b/adonet/archive/2011/03/07/when-is-code-first-not-code-first.aspx
Background:
I started to create logical database model for ASP.NET MVC web site. I used visual designer for Entity framework that ships with VS because I have used it before.
But now I already have 33 classes and I'm not finished (including quite some inheritance and a lot of associations). I'm afraid that it would be too complicated and time consuming for me to manually set all the table mappings and than generate database tables. I've no experience with it - I've done it the other way: classes from database tables and it took me a lot of time to get it work in a smaller project.
Question:
How can I easily and quickly create database tables for logical model (class diagram) in .NET / VS ? It would be great if it was possible automatically. I have never worked with LinqToSQL visual designer and it seems to be no reference on the web on how to create database tables from LinqToSQL classes. Is it possible at all ? If not is there any way to create database tables with Entity framework automatically - without having to specify table mappings ?
And one side question: if I used LinqToSQL classes are that going to commit changes to database every time I change properties ? Or is some caching taking place there ?
Entity framework has a concept called "Model First", which generates the database model from you model, hence the name.
You can read about that here: http://msdn.microsoft.com/en-us/data/ff830362
However, my personal favourite when it comes to Object Relational Mappers is NHibernate with the addition Fluent NHibernate. They have a concept where you work with your domain model rather than you data model and you use conventions to control your mappings. It's pretty neat. You can get started with some pretty good examples by looking at this code here: https://github.com/sharparchitecture/Northwind/tree/master/app
Linq2Sql is too limited for the case you are talking about. And it has no capability to generate data models from code. In fact, Linq2Sql works the other way around - it generates a set of classes from your data model, much like Entity Framework also can do.
Neither Linq 2 SQL or Entity Framework commit anything until you explicitly choose to do so. They both have a notion of a object context which keeps track of all changes made. When you call "Save", they transform those changes into SQL which is then executed in the database.
Like MikeEast, I've had a very good experience with Fluent NHibernate.
On my project, I use the Automapping feature, which allows me to change my data model almost at will, and the database schema automagically gets updated.
No SQL, no worrying about foreign keys, etc, etc, etc - I love it!
Fluent NHibernate Automapping
Finally I have sticked with Entity framework - tables generating is really plainless once I learnt how to deal with database connections...