I have seen this question a lot around here, however all the solutions involve using EF code-first. I used model-first using a designer to layout me entities and their relationships. I would like to update my production server's scheme without losing the data.
Because I am new to this I do not know what is the best solution to achieve this goal. Could I manually write the SQL code to create the new tables in my production scheme than use database-first to import the .edmx into Visual Studio? Would that solution work?
Or can I generate the code-first representation of my .edmx and then use that migration process?
Please share some knowledge.
Thanks everyone
Related
Have recently been playing round with Entity Framework to see if it's suitable for our needs. So far have just been creating POCOs to create the Database and then using Migrations to update my schema (Add-Migration/Update-Database etc)
My question is, are we absolutely tied in with the Package Manager Console in order to manage the migrations?
From what I've seen so far, the only alternatives are as follows:
-Automatic Migrations (general consensus seems to be to avoid)
-Excuting Migrations in the code (would still involve using the PMC to create the Migration files, or would involve creating them by hand)
Is there anything else I've missed? It's not a big deal if we are tied in, but would just like to know for sure.
Thanks
I am new to entity framework and MVC, and trying to understand what constitutes a good design approach for a new application.
There are several ways of using Entity Framework. However, for my project, the best looking option is DB First. I've played around with an EDMX file, and I have got as far as using the DbContext code generator to create my wrapper classes.
I plan on using the repository and unit-of-work patterns, and using ninject for DI.
However, it does not seem "proper", from a SoC point of view, that whilst my respository will hide the implementation of the data store (EF) from my code, the model classes themselves are very much EF flavoured.
It seems that using EDMX-based approaches to EF blur the separation of concerns. Only POCO support seems to allow a true separation, but POCO has some other limitations that I don't like.
Am I missing something, or does using EDMX have this drawback?
Are people using an auto mapper to convert between the entity model and another, clean, SoCced model?
thanks
Tian
I don't have a strong opinion on the Separation Of Concerns question, but I have used both the standard ADO.Net version of EF and POCO and it is not difficult at all to customise the output of the the T4 code generation script for POCO to address any concerns you have about the structure of the objects created. That sounds like it would probably be a good starting point for what you are looking to do.
Once you know you are looking for T4 templates there are quite a few tutorials and a lot of helpful SO questions that can give you an idea of what you need to do.
Is there a template or tool to generate code from the database directly? I want to use model first scenario but do not want .edmx file for mappings. There is a database with many tables and I do not want to write all the classes (I am lazy) for that. So, is there a template to generate the code and set the annotations/use fluent api for defining the relationships, etc automatically from the existing database?
This would be helpful in the following scenario as well. Say, I was using .edmx with POCOs and now I do not want the mappings in the .edmx file. I want the mappings in the code. It would be great to have a tool or a template to generate the mappings in the code from the existing database.
I am starting on learning EF 4.1. I think "Code first becomes model first in version 2 i.e. after the database is created/released (in version 1) and needs some changes". Is that really true? I'd love to hear some comments. Thanks.
Check out the 'Reverse Engineer Code First' feature of the EF Power Tools CTP1 that was just released.
For generating classes, you can use POCO t4 template generation. Have a look at this detailed link which will help you getting started. That way you will get all the classes generated.
For mapping, you can use Code-Only style for Entity Framework but generating classes and context using POCO template will have far more advantage over creating the mapping yourself. Imagine adding new tables or modifying the tables, it will involve more work. But I will certainly love to know if there is any mapping tool for that.
It is possible that you are using EF-provider Devart dotConnect for Oracle when working with Oracle database. In this case the following information will help you to choose the tool.
The first version of Entity Framework Power Tools also contained the capability of generating a Code-First model with fluent mapping from an existing database. Although useful, this functionality is limited as regards its flexibility: the developer can only set the connection string; following that, classes are generated from all database objects available to the user. That is not extremely convenient, since in Oracle, for example, numerous schemas containing hundreds and sometimes thousands of tables are available to the user.
Rather than resort to this limited functionality, the users of Devart ADO.NET providers can avail themselves of impressively robust design-time development capabilities of Entity Developer, an EF-designer delivered with Devart providers. Also possible is the choice between the Database-First approach, as provided in EF Power Tools, and the Model-First approach, within which Code-First classes are created in the EDM-designer.
When compared to EF Power Tools, the Database-First approach to the development of EF Code-First models also allows selecting objects that must be available in the model, setting naming rules for the generation of class names and properties and so on. Besides, the resulting model can be modified and improved in the designer.
To better meet developers' needs, Code-First code generation in Entity Developer both for C# and VB is based on the T4-template that is easily accessible and can be modified in feature-rich T4 Editor contained in Entity Developer.
For more information on Code-First development in Entity Developer, see "Entity Developer – EF Code First DbContext Template"
http://www.devart.com/blogs/dotconnect/index.php/entity-developer-ef-code-first-dbcontext-template.html
I used Entity framework with a database having around 50 tables and it worked just fine.
But just to see what happens with a larger database in terms of number of tables/entities i tried to implement the Entity Framework to a database that had around 100+ tables.
Once i selected all the tables and clicked on the Finish Button on the Entity Framework Wizard its just hanged my VS 2010 so i could not get any results.
My Questions are as below;
1.If I have larger Database in terms of Table/Entites as described above, Is it a good idea to use Entity Framework?
2.What will be the better approch using Entity Framework to work with database?
3.Should i create multiple DataContext or EDMX files with lesser entites in it?
4.How will these different DataContext interact with each other?
5.Is there any recommended no of tables that should be used while working with Entity Framework?
#Will is correct that the limitation you're seeing is in the designer, but it's not the only one, so Code-First doesn't necessarily fix the problem.
If the designer seems slow, it's inconvenient, but not the end of the world. Runtime performance considerations are another thing altogether. For performance-critical tasks and tuning, you'll want to understand the whole pipeline.
View generation, e.g., takes time. You can move this to compile time with manual work.
1.If I have larger Database in terms of Table/Entites as described above, Is it a good idea to use Entity Framework?
I certainly wouldn't let it stop you.
2.What will be the better approch using Entity Framework to work with database?
3.Should i create multiple DataContext or EDMX files with lesser entites in it?
That's certainly a good approach for many applications.
4.How will these different DataContext interact with each other?
Mostly not. A single, giant data model is often a bad idea due to service coupling. However, you can selectively couple them by sharing portions of the models with includes in EDMX or classes in code-first.
5.Is there any recommended no of tables that should be used while working with Entity Framework?
One way is to use smaller models, as you've suggested. Another way is to work around the runtime performance issues which sometimes come with larger models (see the links I give above). Like any potential performance "problem", write correct code first, then profile and fix the slow parts. Usually, query tuning is more important than model size anyway.
EF, probably yes. The toolset in Visual Studio? Not so much, apparently. For a database this big, you might want to do Code First.
I think EF itself have't performance limitations for count of tables, but have for count of records in particular table. You have to do manual object-db relation (i.e. manual write classes for tables and corresponding attributes) for go away from design problems in VS10.
It's clear approach in Hibernate, but in EF probably not.
Entity Framework is the best way to develop database applications.
I used to develop my applications using LINQ to SQL but since Microsoft is not going to support it in future, it recommends to use Entity Framework.
By the way, Entity Framework 4 in .NET 4 has much better performance than previous versions.
I'm currently developing an enterprise application using Entity Framework and it supports all my needs.
I suggest to use Entity Framework.
I currently use the Entity Framework designer to generate my persistance objects and I also user POCO view models for the ASp.NET MVC view.
I've read and listened to a lot of people talking about the good support for POCO's in EF4 as well as POCO's in general but I can't seem to work out what advantage, if any I'll get from using them.
In our application, we WILL be using SQL Server so it's not like we need so separate out for different databases.
Why would I want to use POCO's as opposed to the designer generated classes?
POCO offers better extensibility/reuse of your Domain Model as you're not tied to any specific ORM framework.
Answered here :What are the 'big' advantages to have Poco with ORM?
Easier to unit test
I find when you have many entities (100+) using the designer is painful and POCO objects are easy to create and maintain.
With POCO's you can "Code First"
http://weblogs.asp.net/scottgu/archive/2010/08/03/using-ef-code-first-with-an-existing-database.aspx
+1 for with POCOS you can code first. In fact you can create and test your entire application before you even write your first line of data access code. This is how it should be, it's a perfect application of the SRP. Your domain object should not know or care how they are being persisted.