We have one DB with many tables. We decided to create different models instead of just one containing all the tables.
We'd now need to associate an Entity (table) in ModelA with an Entity (table) in ModelB. Obviously at DB level this is possible (a simple foreign key) but it looks like it is not at model level.
Suggestions?
Your database is composed of one big model with many tables and relationships
But in your application if you are going to split it into two models then there is a lot of chance of having "Entities" that will be needed in different models.
You can create two different entities instead each representing what is needed from the table in each particular model and map each entity to the same table in Entity Framework
See the image below
The black boxes are your tables, the red and blue are your entites.
As you can see the whole database is related but your ModelA includes only some fields on the common table, while Model B includes its own set of fields from the common table.
Related
I have two tables - ContactInformation & EmailAddress - which have a many to many (* : *) relationship. After making this association in the ADO.NET data model and generate the db from it, a table titled ContactInformationEmailAddresses which maps the two tables is created in the Entities Container.
Unlike when I scaffold views which have a 1:* relationship, there's no entries available for its counterpart in the view when I scaffold either one and scaffolding off the combined table isn't an option even after updating the model from the db.
My question is simply: is there an automated way to generate the creation form for ContactInformationEmailAddresses that will have the EmailAddress entry field?
At present the scaffolding templates don’t support generating views that require the selection and association with more than one entity – the “many” end of the association.
Make sure to check out this blog article
http://blogs.msdn.com/b/mcsuksoldev/archive/2013/09/20/managing-entity-relationships-with-mvc-scaffolding.aspx
Lets say I have Customer, Order, OrderDetail classes in the business layer (It's a simplified version of my problem).
I have also an old (existing) database that has one global table where every row of the table contains the information of Customers-Orders-OrderDetails; for example:
CustomerID, CompanyName,Fax,OrderID, OrderDate,ProductID,UnitPrice,Quantity
(in this way there are duplicated information of a Customer in different rows).
In the future I'll have a new database (with different table Customers, Orders, OrderDetails), and I want to use the same program.
I want to use EF CodeFirst to mapping to the old database and in the future to the new database
Which is the best solution?
Design a business layer with a global class that contains the information of Customers-Orders-OrderDetails. So the mapping of this class
with the old database using EF4 in the data layer is trivial.
In the future I'll modify both business layer and data layer for the new database.
Design a business layer with Customers, Orders, OrderDetails classes. In this case is it possible to map these classes to the global table of the old database? How ? (the problem is that the Customer-Order is one to many).
In the future I'll modify only data layer for mapping the new database.
This will work for now and later you will have to modify everything working with a global class - it can be a lot of work.
It is not possible to map one table to three entities where two have one-to-many relation between them with EF.
Use third approach. Load one class as described in first approach but immediately convert result to three classes from the second approach. The reverse operation will be done in case of persisting changes. Wrap this code in single place - repository. Your application will use three classes and it will not have any knowledge about the way how they are persisted. Once you change the database you will only remove additional conversions from the repository and work directly with Customer, Order, OrderDetail loaded and persisted by EF.
I have database with 3 tables as follows:
From within Visual Web Developer 2010 Express, I create an EF model using Entity Data Model Wizard. I select the 3 tables. Unfortunately, the resulting EF model does not contain the junction table, i.e., QuestionsTags table. The following figure shows the EF model diagram.
My question: Why cannot the Entity Data Model Wizard work for many-many related tables?
This is the difference between physical model and conceptual model. In physical model you use junction able to define M:N relation because relation databases don't support it natively. In conceptual model you do not deal with physical storage. Junction table is not included in conceptual model because it is not needed. You don't need to access it, you need to access Tags related to Questions or Questions related to Tags. Those relations are directly accessible by navigation properties.
Junction table will be automatically added to model only if it contains additional columns (not only FKs to build M:N relation). It is also possible to manually modify (EF4) model and force it to add entity for junction table.
It works. Notice the navigation properties at the bottom of your EF model diagram.
The QuestionsTags table only exists to model the many-to-many relationship in a relational database. When you have objects that don't have to fit into a rigid table schema, you can use a collection on a question object to get all the tags on that question, and likewise, a collection on a tag object to get all the questions with that tag...The Entity Framework models this for you and will populate these collections automatically.
Setup: I have a simple web app that has a handfull of forms, each on a separate page. These forms represent patient data. There is a one-to-one relationship between patient and all these forms/entities. Each form maps directly to a db table and a JPA entity, maybe not the best architecture but it works and is simple.
Question: If form/entity A and form/entity B share a common chunk of data (one of more fields), what is the best way to handle that in JPA. I.E. - If the data gets inserted via form A, I need it to show up in form B as existing data and vice versa. In other words its logical for both entities to contain that data. I believe I will have to move the common data into its own entity and define the relationships that way, but I have tried many different ways and none gets me all the way, at least with basic JPA. Can this be done through pure JPA relationships or will I have to write a bunch of code to make this happen manually. Not looking for code specifically, just the correct way to model this data. Thanks.
If the forms have separate tables with duplicate columns for the common data, then you cannot directly share the data. You will need to copy the data from one Entity to the other in your application. You could use a Embeddable to define the common data, but would still need to copy this Embeddable from one form to the other.
If you put the common data in a 3rd table, then you can share the data. Form A and Form B would define a OneToOne relationship to the common data.
have two tables in database.
They have completely the same columns, only the difference between them - they have different names.
Lets say i have TableSea with column s Id and Name and TableOcean with the same columns Id and Name.
I want to use EF 4 to be able CRUD operations, i am also want to use stored procs mapping for insert update and delete operations.
I am already created POCO entity for first table and i did create stored procedures and map them to entity model. All working well.
How make it work with two tables without create a new entity for second table?
AFAIK, you can't, and you definitely shouldn't!
If you have two identical database tables, then this means one of the following:
The two tables mirror closely
related concepts (like Sea and Ocean
in your example).
The two tables
mirror different concepts which only
accidentally have the same
properties.
Depending on which scenario is closer to reality, you have these two design options:
Merge the two tables and add a
Type property (column), then map
it to one entity type. You might
have different subclasses to
differentiate between types, or you
may go with an additional Type
property - whichever fits better for
you.
Have two tables. Which means: there are two different concepts. Consequently, this has to be mirrored by two different entities in the business model.
In any case, having an entity table in the database means having an entity class in the business model. If there's no such 1:1 - mapping, then clearly something is wrong with the design!
Thomas