Is there an equivalence in Entity Framework to NHibernate SchemaExport?
Given I have a working Entity-Model, I would like to programmatically initialize a database.
I would like to use this functionality in the setup of my integration tests.
Creating the matching DDL for an Entity-Model would also suffice.
Yes - given that you're working with Entity Framework 4 (which is, confusingly enough, the second version...)
Edit: This is the way to do it with just EF4. In my original post below is described how to accomplish the same thing with the Code-Only approach in EF CTP3.
How to: Export model to database in EF4
To export a model to database, right-click anywhere in the designer (where you don't have an entity) and choose "Generate database from model..." and follow the steps described in the wizard. Voila!
Original post, targeting EF4 CTP3 and Code-Only: This is code I use in a little setup utility.
var builder = new ContextBuilder<ObjectContext>();
// Register all configurations you need here
builder.Configurations.Add(new EntryConfiguration());
builder.Configurations.Add(new TagConfiguration());
var conn = GetUnOpenedSqlConnection();
var db = builder.Create(conn);
if (db.DatabaseExists())
{ db.DeleteDatabase(); }
db.CreateDatabase();
It works on my machine (although here I've simplified a little bit for brevity...), so if something does not work it's because I over-simplified.
Note that, as TomTom stated, you will only get the basics. But it's pretty useful even if you have a more complicated schema - you only have to manually write DDL to add the complicated stuff onto the generated DB schema.
Nope, and seriously I do wonder why nhibernate bothers having this.
Problem is: an O/R mapper has LESS information about the database than needed for non-trivial setups.
Missing are:
Indices, fully configured
Information about server side constraints, triggers (yes, there may be some)
Information about object distribution over elements like table spaces
Information about permissions
I really love a test method (please check that database is good enough for all objects you know), but generation is VERY tricky - been there, done that. You need some serious additional annotations in the ORM to be able to even generate sensible indices.
Related
I'm writing a quick prototype project. I don't want to use EF migrations because I don't really understand them yet. The app imports data from a file into a DB. If the schema changes, my strategy will be "drop the tables and let EF rebuild them".
This works OK for adding data at startup, but I had trouble deciding if I needed to build the DB. For example:
var inputCount = parsedData.Items.Length;
var dbCount = _itemsContext.Items.Count();
if (inputCount != dbCount)
{
// Do updates/inserts
}
Since the table doesn't exist, I can't query for a count. I could handle the exception but that felt a little messy. I just needed EF to create the table if it's not there. Everything I read walked me through adding migrations to the project but it feels like a feature I didn't want.
(I couldn't find a clear duplicate of this with the questions my use case generated. Now that I know the answer I can find questions that discuss it, but I hope this post helps guide someone that way.)
The DbContext type has a Database property that gives you sort of backdoor access to things EF manages. It has a convenience method EnsureCreated (also an async implementation) that will ensure the table exists when the DbContext is configured.
Credit to this EF tutorial for explaining this and a handful of other exotic initializaton scenarios.o
Based on some other things I've read it seems this makes adding migrations later impossible, and perhaps Database.Migrate() does the same thing more safely. So have an idea whether you want migrations at all before you do this (but if you plan on using migrations, it seems silly to be doing manual initializations?)
Working on a brand new project from the ground up. That means the data model is in a constant flux, doubly so because things are, inevitably, not as well planned as they should be. Model classes are being created and changed fairly regularly.
The plan was to use the latest version of EF with all the neat code-first stuff in it. But we're constantly tripping over the limitations the framework has in terms of adding or updating tables. The initialization options seem to allow only the complete deletion and re-creation of the database, which isn't really ideal.
I've had a look at the migrations. But this seems a sledgehammer to crack a nut: we don't need to detail every single small change and update with a new migration scaffold.
Are there some better strategies to deal with this? For instance, I started writing some unit tests to pre-populate one of the contexts with some test data, but because this causes the whole Db to drop and re-create, it causes problems with all the other contexts. Or perhaps making use of a custom initialiser to seed the data for us? How can we easily exclude these in production code?
We're also wondering about perhaps abandoning code-first and going back to EDMX diagrams. At least that way changes result in updated SQL commands which can be run directly against the database.
Any suggestions gratefully received.
I think, imho, that:
as the database schema must at least match your model you should/must detail every single change, and code first migration allows that and trace the changes over time
code first migration also allows to migrate the database schema for you
code first migration also allows you to produce sql that allows you to migrate the schema
For these reasons code first is as good (if not better) as the edmx approach
Please take few minutes to implement http://msdn.microsoft.com/en-us/data/jj591621.aspx
One other point, always imho and in a perfect world, if you unit test the business of you model you should not need the DAL, use generic collection. Be aware of different comportement of linq to object vs linq to entities, for example concerning the case sensitivity.
I have to create a new project and (as usual) is with an existing SQL Server database.
I used to use EF Code First connecting with my database, opening my EDMX model designer and then right click --> Add Code Generation Item. (http://weblogs.asp.net/jgalloway/archive/2011/02/24/generating-ef-code-first-model-classes-from-an-existing-database.aspx) Easy.
But now I've discovered there's something called EF Power Tools that allows me to do Reverse Engineer Code First (cool name!) and get the same (http://msdn.microsoft.com/en-us/data/jj200620)
Do you know the difference between the two options? Which one is better?
Thanks in advance.
(Sorry if this question was previously asked but I didn't find it.)
The difference is that the edmx approach is not code first, but database first with DbContext API. You will always use the database as the source of model changes.
EF Power Tools produce a truly code first model with DbContext: from then on you will change the class model first and modify the database accordingly (e.g. by EF migrations).
Neither is "better". DbContext API is easier to work with than ObjectContext, but both approaches use the former. It's up to you to choose whether you want to work database first or code first. It's a matter of personal preference and it may depend on who maintains the database structure. With database first it is easier to respond to changes someone else imposes on the database structure.
As far as workflow goes for database first, adding to what #Gert-Arnold said:
With database first it is easier to respond to changes someone else imposes on the database structure.
If someone else is managing the database changes, I'm finding it far easier to use the EF Designer. You get an updated database, then just right-click in the EF Designer and update the model from the database. You can use source control to easily view what has changed.
Also, if you only need a subset of tables from the database, reverse engineering causes alot of work having to go back and remove classes and properties from the context.
I found re-reverse engineering via code-first to an existing database to be just too much of a pain trying to figure out what changed and how I needed to update code that used the context.
The method - Entity Framework Code-First - looks good. But its very difficult to create all the classes for a large database.
Is there any easy way to generate the Entity Framework Code-First classes?
You can use the recently released Entity Framework Power Tools CTP1. The tool gives you the ability to reverse engineer code first, meaning the Database will be mapped to Code.
Note that all tables in your large database will be mapped. There currently is no way to choose which tables will be mapped to code. Reading through the comments, this feature will most likely be implemented in a future release.
The point of EF Code-First is that you define your domain model in code, then your user-interface and database can be easily generated from that domain model. This has a number of advantages including reducing the amount of tedious code which needs to be written, and helping to ensure your database, your domain model, and your UI match each other.
However, at some point you are going to have to write your domain model - there's no way that can be "generated" (by which I assume you mean computer-generated) as it is personal to your application.
If I've misunderstood your question, please leave a comment and I'll update my answer.
If you want to use the code-first model, but already have an existing database, you can use the Entity Framework Power Tools to generate classes.
If you're reading this after May/2012, the above tool may be out of beta!
No there is no way to generate classes for you if you are using code-first. Code first means that there is no model and no database so you can't generate classes unless you have some upfront design in any case system (UML) which will autogenerate code for you. Simply generating classes without any input about how they should look like sounds like AI from Sci-fi, doesn't it?
If you already have databse you are not using code first but database first. In such case you can have your classes generated.
Check out the link below. It's a program that will generate POCO classes from your databases. I think that's what you're looking for.
http://msormcodegen.codeplex.com/
Generate the code from the database first using database first generation and then modify the resulting code to start your code first version
I have now decided to try out ASP.NET MVC 3.
My host provider, however, only supports MySQL and therefore I have to figure out how to use MVC 3 with MySQL.
I have also decided that I don't wanna do any SQL code if I can avoid it, and I would also like O/RM without too much effort. I understand that the Entity Framework will actually help me accomplish this to a large extent.
I have been trying to get into the various ways of using the EF, with the database first, model first and code first approaches supplied by the framework.
So far, I have not had much luck, and I find that the examples available all use very different approaches that confuses me a lot.
I might begin by asking for guidance on getting a few concepts right.
First of all, the Model (in MVC) is actually more like a ViewModel, that represents something (Users, Posts, etc.) in terms of Properties is more or less simple classes. I.e. the model is where the data from the database gets mapped to an object (the O/RM). Am I right?
A repository is a wrapper that encapsulates a specific way of retrieving data for the models. For instance, a DatabaseRepository or a FakeTestRepository.
Should I have a single repository in my MVC project, or a repository per database table, such that I have a UsersRepository and PostsRepository?
Should the repository be a model for itself, not a model at all, or tied to individual models (so that UsersRepository is part of the UsersModel)?
I have tried to use the EF's model first approach, and for a simple test I just have created an empty model and added the entities "Author" and "Guide" that are related by a one-to-many relation.
When I then, in Visual Studio 2010, "Generate database from model", I get the corresponding sql code. I want this database to be created in MySQL. How can I accomplish that?
Are there some code examples for MVC 3 with MySQL and O/RM where the creation of a small site is demonstrated?
Thanks.
Concerning EF Model First approach: take a look at this Tips & Tricks article. We have described this common situation in it (it is Oracle-specific, but dotConnect for MySQL contains the "Devart SSDLToMySQL.tt" template).
As for the rest of the questions - there is no definite answer. Choose the approach that suits you better.
In my point of view, you should try the code first. And as you said that your host only provides MySQL you can also use MySQL database as a database I personally use MySQL. Concepts are the same but logic is different you have to code it a different way. But from my point of view, you can use MySQL as a database service.