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.
Related
I have 2 Entities, related by a many-to-many relationship.
Thing<<->>Tag
There is one NSArrayController controlling the entity "Tag", bound to the managedObjectContext. By the array controllers add: and remove: action i can add instances of tag to the collection.
There is a second NSArrayController controlling "Thing" entities, also bound to the managedObjectContext.
So each of the controllers manages all instances of their entity.
Now, let's say there are 5 "tag" and 3 "thing" instances already created by their array controllers.
I'd like to link individual tags to a thing. I just want to create the relationship between an existing thing to an existing tag instance.
Is addObject: of NSArrayController the right method for that? Or does it create a new managedObject?
Would it be equivalent to:
NSMutableSet *tags = [aThing mutableSetValueForKey:#"tags"];
[tags addObject:existingTag];
?
Is there some best practice for a tagging system?
I've found it helpful (in the latest version of Xcode) to select the entity in the core data modeller, and then go to the file menu, and select new file -> Core Data -> NSManagedObject subclass. It automatically creates a class with the necessary members AND ALSO methods for adding objects in the toMany relationships.
If you've done that, then you just need to get ahold of the thing instance to which you want to add a tag and you can call the method declared for you to do so. How that method is named is obvious from the header file generated.
I am just getting into Entity Framework for the first time beyond simple examples.
I am using the model-first approach and am querying the data source with LINQ-to-Entities.
I have created an entity model that I am exposing as an OData service against a database where I do not control the schema. In my model, I have two entities that are based off of two views in this database. I've created an association between the two entities. Both views have a column with the same name.
I am getting the error:
Ambiguous column name 'columnname'. Could not use view or function 'viewname' because of binding errors.
If I was writing the SQL statement myself, I'd qualify one of the column names with an alias to prevent this issue. EF apparently isn't doing that. How do I fix this, short of changing the view? (which I cannot do) I think this does have something to do with these entities being mapped to views, instead of being mapped to actual tables.
Assuming you can change the model have you tried going into the model and just changing one of the column names? I can still see how it might be problematic if the two views are pulling back the same column from the same table. I can tell that when working directly with a model mapped to tables, having identically named columns is not a problem. Even having multiple associations to the same table is handled correctly, the Navigation Properties are automatically given unique names. Depending on which version of EF you used you should be able to dig into the cs file either under the model or under the t4 template file and see what's going on. Then you can always create a partial class to bend it to your will.
Summary of the question: How do i scaffold two or more tables with linq to entities.
I cant find an example; they always scaffold only one table.
Details:
If I have two tables and I use LINQ to entities with a t4 template for dbcontext capability like such:
Table1
Name LastName PositionId
Jose j 1
Table2
PositionPrimaryKey PositionId PositionDescription
1 1 MainProgrammer
If I had these table mapped with linq to entities how would I scaffold them?
Then i put Table1 as my Model class.
I have my employeesentities as dbcontext
But that only creates the values for table 1 and not 2.
If I create a new model that contains both entities, it says is not part of Employeeentities and the class could not be modfied to add my new entity.
So, you have a 1:1 relationship between these tables? If yes, I suggest you creating an entity by hand, set its defining query to the necessary join, and map Insert/Update/Delete to stored procedures in the Mapping Details screen. It involves some (quite simple) sql, but it is the cleanest way for your code above.
If it's not a 1:1 relationship, you need to modify the t4 template to conditionally create the fields of the linked property (it has to navigate the property, and based on some condition, like you say "if property is called Table2", create the extra fields). If you have already done so and it doesn't work, maybe there's something going on with the selection of properties used by MVC scaffolding. It might use reflection and choose only primitive types.
I have a doctrine data model with a table Person, however my Symfony application is only part of a bigger web application, which is build in Joomla. For a module, I need to add a number of fields from a view, which spans 8 tables with the person table. The view is already established for the Joomla part of things.
Short of creating a schema for all the tables involved, is there a way to arbitrarily join the view in my tableMethod? As another shortcut I am thinking of creating a minimal schema.yml table to just represent the field of the view that I need.
another solution would be to use native sql with doctrine
I’m having a philosophical problem with understanding how to use Models on MVC3.
I believe the problem lies from the fact that I come from WebForms :--)
Let's say I have 10 tables on my DB and as expected when I get them into my EF4, I get those Entity classes that represent the tables (and all their FK integer values).
When I want to display data on the View, I cannot display a select * from table because those FK integers means nothing to my users …and also because some data lies on related tables.
So my understanding is that I can create a Stored Proc, create a Complex Type that represent the actual data to display, coming from separate tables via different SQL joins.
QUESTION 1:
On the view, id MVC compliant to use as #model ..that Complex Type?
or shall I always use Models that are created on the Models folder? And if so, does that mean that I have to replicate the Complex Type on a new model inside the Models folder?
Question 2:
Is this the right way …to create specific SP to collect data that will be displayed or ..is it better to use linq and lambda to be applied to the EF4 Types that come from importing the DB into the EMDX designer.
Thoughts ??
FP
The correct way is to always define view models. View models are classes which are specifically tailored to the needs of a given view and would be defined in the MVC application tier. Those classes would contain only the properties that would be needed to be displayed by the view. Then you need to map between your domain models (EF autogenerated classes?) and the view models.
So a controller action would query a repository in order to fetch a domain model, map it to a view model and pass this view model to the view. Top facilitate this mapping you could use AutoMapper. A view shouldn't be tied to a domain model and always work with a view model. This works also the other way around: a controller action receives a view model from the view as action argument, maps it to a domain model and passes this domain model to the repository in order to perform some action with it (CRUD).
So a view model could be a class that is mapped from multiple domain models or multiple view models could be mapped to a single domain model. It all depends on how your domain looks like and how do you want to represent the information to the user.
As far as validation is concerned, I distinguish two types: UI validation and business validation. As an example of UI validation is: a field is required, or a field must be entered in a given format. A business validation is : the username is already taken or insufficient funds to perform wire transfer. UI validation should be done on the view models and business validation on the domain models.
I'm not sure why you need to use a stored proc, LINQ to Entities is able to generate complex types without needing to create stored procs (in most cases). You select subsets of data, just like you would with regular SQL.
As Darin says, the use of a View Model is appropriate for situations where you have a lot of complex data that isn't represented by a single entity. This View Model would contain multiple entities, or even multiple collections of entities. It all depends on how your data needs to be consumed.