I'm using VS2010 Beta 2, I have a Complex Type called Address with the following properties:
Street
City
CountryId
I have a Country Entity defined in my Model, but I can't seem to find a way to add a reference (Navigation Property) from the CountryId property of my Complex Type to the Id property of my Country entity.
I'm I going about this the wrong way or is this something that I can't do with the designer??...
Another option I have is just creating an Address entity, but it just doesn't sound right to me.
No, you can't do this, because it goes against the idea of what complex types and navigation properties are. Complex types have value semantics, rather than reference identity. Navigation properties are first-class entities and have reference semantics. Therefore, they cannot be part of a complex type. As it seems you've discovered, the solution is to partition the parts with value semantics into the complex type, and add it to an entity containing the navigation properties you require.
Ok,
It seems like the current version of the Entity Framework doesn't support a Navigation Property or foreign key within a Complex Type.
The other sensible option is to create a separate Address Entity, which will have all of the foreign keys it needs, and then create Navigation Properties within all my other entities.
Related
Let's say we have a table of countries. Each country has a name, a short name and some kind of code, e.g. by ISO. In UML, I can model the country names as an enum, the short names as an enum and a third enum for the country codes. But then I always have to keep these three enums in sync. Bad idea.
So, how to I model this more elegantly? Is there a way to model 'tables' in UML or do I have to make these enums nested somehow?
You will model that via properties
The Country class (I left out the attributes like name) will return the country code via a property Code which depends on the according enum. Other coding (with according naming) would be return in the same manner.
You need to decide on some leading coding (say it would be CountryCode. In order to get other codings you would need to provide operations to either Country or CountrCode like asISO():String and the like. This is a design decision. If you have independent codings which do not have mappings to each other you will run into trouble.
Disclaimer: Please do not suggest database-model redesigns / database model concept flaws. This question is about the case described, there is no way to change that case apprently.
Assuming i hava a table fruits, with name, color and type as fields
This means, all apples have the type=apple, all oranges have type=orange and so on.
Now creating a JPA entity/model called Apple with those 3 fields mapped and the Table=fruits, i want to create a AppleRepository where the argument type is statically set to apple and not visible to the outer consumers.
So i do not want to offer
AppleRepository.findByTypeAndNameContains with requiring the caller to now to set type to apple
but rather just
AppleRepository.findByNameContains while type is statically set to apple.
(With the same method i would then chose to Orange and the OrangeRepository using type=orange)
I understand i could use #Query to write a custom query where type is just statically included and only mapping the dynamic parameters... but
Question:
Is there a elegant way to implement that without using #Query?
What you have is the principle behind the "singe table" inheritance strategy. It consists in storing all the entities in a hierarchy inside a single table, and distinguishing them using a discriminator column (i.e. your type column).
See the documentation for details
I'm new to MVC & EF. I'm developing the MVC project with model first approach. In my project i have different entities like-customer,employee,product,etc. and i created association between them like 1 to many in customer-employee like this. and after creating this association; it is generating navigation property in customer entity i.e, Employees (collection object) for employee entity.
I want to modify this collection class and i want to add some more methods on it. Is it possible? How to do this if possible?
thanks.
The property is generated with ICollection<Employee> type. You can in theory create your own class implementing this interface and initialize the property for example in Employee constructor but the property will still expose the interface. Changing return type of the property requires change in class generator (you should use T4 template which would make this easy task). By changing property's return type to your collection you can lose some EF functionality.
I have three views that I've manually created in the DB.
First view is "Region", the second is "FIPS" and the last is a many-to-many between them called "Region2FIPS". These are all views, and I only need read access the data, so I'm not worried about having updateable views.
I have added each of these views to Entity Framework, and created the appropriate associations between them.
Region to Region2FIPS is a 1 to many.
FIPS to Region2FIPS is a 1 to many.
The "Region2FIPS" view contains only two columns, one called "FIPSID" the other "RegionID". These column are associated with their respective views in the relationships I defined above.
When this type of association is made on tables in the DB, Entity Framework knows that it is a many-to-many relationship and it creates a navigation property on "Region" called "FIPS" that I can use to navigate through the child collection of FIPS. It does likewise for "FIPS" to "Region".
However, when done manually, with views, it does not exhibit that behavior. Instead, my "Region" object has a collection of "Region2FIPS" objects, which each have a navigation property called "FIPS" which is of type "FIPS". And my "FIPS" object has a collection of "Region2FIPS" objects, which each have a navigation property called "Regions" of type "Region".
I assume this has something to do with the fact that I can't create foreign key references on the views, so entity framework doesn't realize the many-to-many relationship. But I thought that if I manually created the many-to-many relationship between the views it would recognize it and properly handle the navigation between the types. Is there a way for me to force it to do this?
It's possible, but the designer doesn't really help you here. You have to do the mapping manually.
One fairly easy way is to use Code First mapping. But this means your model has to be Code First to begin with. If you're writing a new model, just do that.
If you're using DB First mapping, however, you will have to do the mapping manually. Your SSDL will probably already be correct, once you define the "primary keys" of the views. You would then have to remove the "Region2FIPS" objects from the CSDL (not just from the designer!) and manually patch up the MSL.
Perhaps the easiest way to do this would be to use the designer to automatically map real DB tables (not views) with a similar schema and then replace the table names with view names in the EDMX, using the XML editor.
I can see that Extended Data Types can have Array Element which seems to make it a composite type. I'll be looking into that later.
What are the relations used for? MSDN was woefully crap at explainined what it would actually be used for. Why would you want to relate a type to a specific table and why would other tables using the type care?
When I create a new 'PersonTable' table I could have a key field called personId, creating/using a new Extended Data Types called personId and adding the relation you've mentioned. Now when I add our EDT to other tables we do not have to specify either labels or relations to our PersonTable as this it's defined by the extended data type.
In a related form (e.g. PersonSkillsTable) where our personid field has been added to an existing table it will now automatically create the dropdown/grid to select a value from our persontable. We didn't need to add our persontable to the form's Data Source.
Automatic relations between tables
Automatic lookups
Automatic "Go To Main Table" menu option after right-click