I've got Doctrine 2 set up on Zend Framework 1.10 and have all the autoloading set up correctly including all necessary config settings in the application.ini. What I need to do now (or so I believe) is to create my Entity classes with mapping information so that the entity manager can work with my database.
What I don't want to do is write the Entity classes by hand as this will take ages but I can't seem to work out what to do next. Does the command line tool have functionality to create the entities, proxies and all other necessary classes from an existing schema?
You can use the reverse engineering tool of Doctrine http://www.doctrine-project.org/docs/orm/2.0/en/reference/tools.html#reverse-engineering
But it also doesnt detect everything as noted in the reference.
Your best bet is to reverse engineer and filling the rest with manually IMO.
Using the command line tool:
./bin/doctrine orm:convert-mapping --from-database xml ./bin/tmp
This will generate your xml mappings. Then, ensure that when configuring Doctrine CLI tool you change the driver to the XmlDriver
$driver = new \Doctrine\ORM\Mapping\Driver\XmlDriver(array(
APPLICATION_PATH . '/../bin/tmp'
));
$config->setMetadataDriverImpl($driver);
My CLI configuration uses Zend_Application, so I'm usually changing this in my Bootstrap.
Now run
./bin/doctrine orm:generate-entities ./bin/tmp
The Xml Metadata Driver is required in order for orm:generate-entities to convert from xml to entities. If you use the Default Annotation Driver, it will convert entities in the annotation driver path to entities which is not what we want here.
Related
Iam using EF 6 with database first .. and every time I update the scheme : all my editings to the edmx file (mainly for defining db built in functions) are lost .. but using code first I can add my dbmodelbuilder calls in a separate file with partial class .. and by that I can also use all the nuget packages that targets code first such as EntityFramework.Functions.
Thanks for helping
You can use Code First from database option when you are creating your ADO.net entity data model. This will give you the code first classes that you can edit.
After creating your model you would need to stick to using the code first model otherwise you will need to regenerate your code-first after every database change...
Download the EF tools here.
I have been using Database First Entity Framework (EDMX) and SQL Server Data Tools Database Projects in combination very successfully - change the schema in the database and 'Update Model from Database' to get them into the EDMX. I see though that Entity Framework 7 will be dropping the EDMX format and I am looking for a new process that will allow me to use Code First in Combination with Database Projects.
Lots of my existing development and deployment processes rely on having a database project that contains the schema. This goes in source control is deployed along with the code and is used to update the production database complete with data migration using pre and post deployment scripts. I would be reluctant to drop it.
I would be keen to split one big EDMX into many smaller models as part of this work. This will mean multiple Code First models referencing the same database.
Assuming that I have an existing database and a database project to go with it - I am thinking that I would start by using the following wizard to create an initial set of entity and context classes - I would do this for each of the models.
Add | New Item... | Visual C# Items | Data | ADO.NET Entity Data Model | Code first from database
My problem is - where do I go from there? How do I handle schema changes? As long as I can get the database schema updated, I can use a schema compare operation to get the changes into the project.
These are the options that I am considering.
Make changes in the database and use the wizard from above to regenerate. I guess that I would need to keep any modifications to the entity and/or context classes in partial classes so that they do not get overwritten. Automating this with a list of tables etc to include would be handy. Powershell or T4 Templates maybe? SqlSharpener (suggested by Keith in comments) looks like it might help here. I would also look at disabling all but the checks for database existence and schema compatibility here, as suggested by Steve Green in the comments.
Make changes in code and use migrations to get these changes applied to the database. From what I understand, not having models map cleanly to database schemas (mine don't) might pose problems. I also see some complaints on the net that migrations do not cover all database object types - this was also my experience when I played around with Code First a while back - unique constraints I think were not covered. Has this improved in Entity Framework 7?
Make changes in the database and then use migrations as a kind of comparison between code and the database. See what the differences are and adjust the code to suit. Keep going until there are no differences.
Make changes manually in both code and the database. Obviously, this is not very appealing.
Which of these would be best? Is there anything that I would need to know before trying to implement it? Are there any other, better options?
So the path that we ended up taking was to create some T4 templates that generate both a DbContext and our entities. We provide the entity T4 a list of tables from which to generate entities and have a syntax to indicate that the entity based on one table should inherit from the entity based on another. Custom code goes in partial classes. So our solution looks most like my option 1 from above.
Also, we started out generating fluent configuration in OnModelCreating in the DbContext but have swapped to using attributes on the Entities (where attributes exist - HasPrecision was one that we had to use fluent configuration for). We found that it is more concise and easier to locate the configuration for a property when it is right there decorating that property.
I'm following an MSDN article on applying the Repository Pattern and the Unit Of Work Pattern to Entity Framework, but I'm stuck at the mapping between the custom-made domain models and the as-yet-nonexistant database.
The article has me create two simple POCOs, Employee and TimeCard. It also walks through creating generic repositories and custom implementations therein. (I'm using the custom repositories so I can try to keep EF dependencies in the data access assembly.) However, they sort of glaze over an important step in the mapping. The article says:
With the POCOs in place we can create an Entity Data Model (EDM) in Visual Studio (see figure 1). We will not use the EDM to generate code for our entities. Instead, we want to use the entities we lovingly craft by hand. We will only use the EDM to generate our database schema and provide the metadata EF4 needs to map objects into the database.
The "Figure 1" it references is here:
But that's all it says on the subject. There's an aside on how to generate POCOs from an EDMX. There's lots of information via Google on how to generate POCOs, generate EDMX from a database, etc. But in this walk-through we already have the POCOs and I need to use them in the EDMX which would, in turn, generate the database (I'm assuming, based on other code-first walk-throughs).
I've added an "ADO.NET Entity Data Model" to the project, which is basically a blank canvas. But I'm not seeing how to add my existing POCOs to that canvas. Do I have to re-create them manually on the design surface (which would be a pretty significant duplication problem in a larger domain)? If so, how do they map to the existing ones?
Typically when you use the designer the flow is the opposite - you create the model with the designer (or create/update the model from the database) and then the code is created for you. The created code can be either the EF1 style code with entities derived from EntityObject and attributes etc. which is created with a Single File Generator which is a part of VS (Code Generation Strategy set to "Default") or the code can be created with T4 templates (Code Generation Strategy set to "None") in which case you need to add T4 templates to your project. EF matches POCOs with Entities from the edmx file by convention (names of entities have to be the same, names and types of properties have to match etc.). In the article for some reason they went the opposite way which is weird since it requires that you create all the entities and relationships with the designer manually (since the designer does not know how to create entities from the code) and make sure that the requirements for the conventions (you may not even be aware of some of them) are met. However when you start with code the better approach is to use the EF Code First approach and skip the designer entirely. Code First can create database from your code. It also contains migrations feature which allows evolving your database along with your code. Finally (as you seem to use Visual Studio 2010) you could use EF6 which allows using all the goodness that was previously only available on .NET Framework 4.5 to be used on .NET Framework 4. See here for more details: http://entityframework.codeplex.com/
*the names are going to change in the new version designer that supports EF6 and works with Visual Studio 2012 and Visual Studio 2013
EDIT to address questions from the comment
If you would like to use Code First would use the DbContext API which is a streamlined wrapper of the ObjectContext API. Here is a walkthrough that should help get you started.
You can still use Code First if you have an existing database - the difference is that you will not be able to use migrations. The easiest way to get started with this is to use EF Power Tools. Take a look at this tutorial to see how to do that.
More help here
I'd like to know if it's mandatory to use DataAnnotations for breezejs ef metadata provider to properly get all configurations for each entity? Alternatively, can one avoid the use of any conventions or data annotations and instead configure a mapping class for each entity with explicit mappings and configurations?
You have several options:
1) You can define the metadata yourself on either the client or server, instead of having it generated from EF metadata. See the Breeze Metadata discussion here
2) You can define this same metadata on the client. See the MetadataStore addEntityType method.
3) Along with either of the two options above, you can 'reinterpret' any json results returned from any web service call with the JsonResultsAdapter. We will have an example of this out within the next week or so. By default, this is done for you, but you can intercept the process.
4) Hybrid use, where some entities are defined via metadata from the server and some from client side metadata are also possible. Similarly, you can choose to implement a JsonResultsAdapter for just selected queries and use the default for the rest.
Hope this helps.
I created Model1.edmx file and accordingly Model1.Designer.cs was also created.
I decided to copy all code from Model1.Designer.cs to dal.cs file and deleted Model1.edmx + Model1.Designer.cs files.
When I try to connect I get error that mapping is failed and no SSDL,CSDL are found.
Is there any way to use Linq To Entites without .edmx file, but just using the code in Model1.Designer.cs?
If you define your mapping in EDMX there is no way to use it without EDMX. EDMX is necessary because the build process will decompose the EDMX files into multiple resources specifying mapping between classes and database. These resources are used at runtime.
If you don't want to have EDMX file you can't use it at all and instead you can try code first approach (more tutorials are available on that page) in Entity Framework 4.1. You can also use helper EF Power Tools to generate code mapping from existing database for you (it can be good to start learning how to map tables from code).