We just found an issue like, when a foreign key relationship is broken, there is no way to re-establish the link in the designer.
Any other such known limitations of Entity Framework designer?
Among other things,
You can't map complex types at all. (Update Fixed in EF v4.)
You must map every column of a table in the storage schema.
Generalizing (2), you don't get a lot of control over the storage schema at all. What you mostly see is the client schema and the mapping to the storage schema.
If you delete a type from the diagram, it's difficult to put it back.
I wrote some thoughts about the difference in philosophical approaches between the Entity Framework itself and the designer in this post.
I think that if you intend to do non-trivial/non-default things in the Entity Framework, you should get used to editing the EDMX. Most other ORMs do require editing XML at some point, for what it's worth.
Related
I have seen that in some systems, relationships are mapped in Entity Framework without being mapped in the SQL tables. What is the point of using Entity Framework to map relationships over mapping them in SQL?
Real answer? No good reason unless you need them in the app, and you don't control the database, and it doesn't have them.
Generally, instead of that, it's a developer who's assuming that "the app does that" in terms of relationships, and also assumes that no other app or process will ever touch that data.
Here's a blog post on the latter: https://blog.greglow.com/2016/05/31/should-my-database-have-foreign-key-constraints/
First, If you use Entity framework in large system, it will reduce much code.
Second, we don't need to concern about how to connect to database.
Third,Entity framework can be used as infrastructure for data services and OData services.
I'm working on a project using EF 6 built using database-first approach. There are several tables that previously had the same 3 properties mapped to a complex type (used in several places throughout code). These properties were designated as "foreign key" columns, although their parent-child relationships were never defined in the database.
Recently, a co-worker went through and formally defined the relationships between the FKs and their parent tables in SQL Server. I am now attempting to update the entity model (update from database), and the new associations did not appear. I have resorted to removing the tables from the model and re-adding them. They now show the proper associations.
However, the mapping to Complex Type is gone. When I try to add it back, the updated mappings destroy the associations on those properties (I get a model error when saving). I am aware that Complex Types do not support associations.
Is it recommended to first remove the associations for the columns prior to re-mapping them to the complex type? Will EF observe the underlying key relationship even though the columns are not visible on the entity?
While I would still like to get some feedback on my questions, here's what I did to solve my issues.
1) Removed the associations generated by EF when deleting and re-adding tables from the database. Note that these relationships are only for the foreign key fields which were to be replaced by the complex type.
2) Followed the MS steps (found here) to refactor the requisite key properties to a complex type
3) Optional: It was necessary for me to edit the EDMX directly as XML in order to remove some lingering associations that could not be repaired with the designer
So far, my model functions as intended. I believe the FK relationships are observed during CRUD operations.
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.
I have a Page table and a View table. There is a many-many relationship between these two via a PageView table. Unfortunately all of these tables need to have composite keys (for business reasons).
Page has a primary key of (PageCode, Version),
View has a primary key of (ViewCode, Version).
PageView obviously enough has PageCode, ViewCode, and Version.
The FK to Page is (PageCode, Version) and the FK to View is (ViewCode, Version)
Makes sense and works, but when I try to map this in Entity framework I get
Error 3021: Problem in mapping
fragments...: Each of the following
columns in table PageView is mapped to
multiple conceptual side properties:
PageView.Version is mapped to
(PageView_Association.View.Version,
PageView_Association.Page.Version)
So clearly enough, EF is having a complain about the Version column being a common component of the two foreign keys.
Obviously I could create a PageVersion and ViewVersion column in the join table, but that kind of defeats the point of the constraint, i.e. the Page and View must have the same Version value.
Has anyone encountered this, and is there anything I can do get around it? Thanks!
I'm not aware of a solution in Entity Framework for this problem, but a workaround could be to add primary key columns to your tables and add a unique constraints on the fields you wanted to act like a composite key. This way you ensure uniqueness of your data, but still have one primary key column. Pro-con arguments can be found under this topic: stackoverflow question
Cheers
After much reading and messing about, this is just a limitation of the EF designer and validator when working with many-many relationships.
I was going to write that you should use a surrogate key, but I don't think this will actually help you. The join table is enforcing a business rule basedon the logical attributes of the entities - these same attributes would be stored in the join table even if Page and View were augmented with surrogate keys.
If you are executing on a server that supports constraints, you could separate the Version into PageVersion and ViewVersion and add a constraint that the two are equal, or use an INSERT/UPDATE trigger to enforce this.
I may have simply misunderstood the intent, but I feel there is something that doesn't seem right with this design. I can't imagine how the versioning will work as pages and views are changed and new versions created. If changing a page means it gets a new version, then it will also have cause new versions of all it's views to be made, even for views that haven't changed in that version. Equivalently, if one view in a page changes, the view's version changes, which means the page's version must also change, and so all other views in that page, since page and view versions must match. Does this seem right?
Consider using nHibernate? :) - or at least for anything more than simple joins in your DB. Im working with EF4 and it doesnt seem mature enough for complex data graphs IMO, at the moment. Hopefully it will get there though!
Is there any other method than nHibernate by wich we can generate db schema from class definition? My classes arn't that complex etc (few one-to-many relations). However I would like to just be able to save my objects in db and recreate schema if needed.
I am stuck with .NET 2.0. I am not that particular about performance for this project, I am just lazy to create tables and write save/load code and deel with nHibernate xml.
Thanks
.NET classes are not compatible with a relational data model. That's why ORMs such as NHibernate exist. Without a mapping which describes the conversion of the model to relational tables you cannot create a DB schema. You could take a look at FluentNhibernate automapping feature. If you stick to the conventions it can create the database schema from .NET classes.
NHibernate can do this. The relevant classes -- SchemaExport and SchemaUpdate -- are in the NHibernate.Tool.hbm2ddl namespace. Here's one example.
Yes, ther are other ways. THis is called "programming" - you may have heard of that. Basically, it is possible to write your own database generator. Been there, done that, long before nhibernate had that functionality (or, actually, even existed).
Sit down, write your own database generator.