I have an application with the following layers:
Specific WebAPI Controller -> Generic WebAPI Controller Parent Class -> Generic Repository Class -> Entity Framework -> Database
The problem I'm getting is that when I try to retrieve an object with related objects, for instance, BlogPost, with Category and User, the latter two are being returned null. I have the proper relationships defined at the Model (which EF can infer from) as well as foreign key relationships in the database.
I figured this is because my generic repository does a Get only for the main class, and does not include the others.
I know I can get the others if I put in "Include", but how can I do this with generic layers? If I override my methods, that will probably mean that I won't be using the generic methods for majority of my implementation.
Is there another way to tell EF to retrieve the child objects without having to resort to Get overrides?
Related
I have been working with C# using a repository design pattern with Entity Framework (EF) that allows me to interact with the database using a generic class for each table.
This repository has all the functions that I would need such as: Adding a new entity into the database, updating an existing entity, deleting an entity, saving the context and so on...
Take, for example, I have an entity called 'Person' in the database. I would create a new class called PersonRepository which had all the functions I would need to change/add a value to the database.
As a result, to interact with the database, you create an instance of the repository class. This then allows you to call the functions of this class which in turn interacts with the database. The idea of this pattern is that all your database calls for an entity are isolated into a single class, this improves testability and separation of concerns.
I am learning how to use Core Data in my Swift programs and it appears to be similar to that of EF in C#. I have created the entities in the .xcdatamodel file and created the associated Cocoa Touch class via the Editor > Create NSManageedObject subclasses option.
I used the 'Category/Extension' CodeGen option, so, I then created a new class called 'Exercise'. From what I have read, this class can contain additional logic such as overriding the prepareForDeletion method. Does this mean I can add the addEntity, updateEntity functions onto this method and then call them from other code files?
My questions are:
Can I implement the same repository pattern that I can use in C#?
I believe this would be on the generated class of my entity (see image below)
Where do I place all my database call functions? If I can use this repository pattern I will place them on there, however, if I cannot, do I place them in a separate code file? Should I place them on the generated entity file which is created for the purposes of adding additional logic?
If I can use the repository pattern, is there a way to get the context injected into this class, or, do I have to call a getContext method each time I want to change it? In C# we can use the services to inject the context into the class each time I want to make changes to the database - I am unsure if the same is possible in Swift.
If I understand correctly, in Swift the equivalent of your 'repository' class could be one of two things. It could be context of core data, which you'd run queries and saves to OR (more likely) you would create a new class or struct that obscured away core data from the business side. Assuming the later, your "dataManager" class would perform all interactions with core data. It could then either return NSmanagedobjects to the business side, or you could map/transform/convert to some other type.
Yes, Exercise is a object that subclasses nsmanagedobject, so it has all the core data features of a managed object, but you can add any custom functions your want.
Your data manager class would perform the queries and return the correct objects. For example data manger.getExercises() -> [Exercises], dataManager.save(_ exercise: Exercise), etc....
You'll need to consider thread safety in your pattern. One option is converting your nsmanagedobjects to struct in your datamanager and not returning nsmangedobjects. Structs are thread safe and using codable you can easily convert between exerciseManagedOjbect and exerciseStruct. Plus, with this dataManager class example, you could remove core data for another persistence option in the future with reduced impact to your app overall.
I am facing a problem with EF 4.1. I am trying to Add a detached object to the DbContext. Problem is it is not the emd mapped object, but derived from it. Changing the mapping is not an option as some teams are using the model with the regular mapped BL-classes, but my project created a derived model for UI stuff. Even with casting I always receive a
InvalidOperationException ("Mapping and metadata information could not be found for EntityType ...").
What I want is EF to treat this as the base class and put the object into the DbSet of the BaseClass. The current EF code is:
Context.Entry(object).State = EntityState.Added
But I am open for other suggestions, even
via IObjectContextAdapter, as long as it can save the Base and the Supertype. This should be simple, right?! Mapping to a new Base-class instance is not good idea as the main objects temporary Id would not be updated after saving...
Thanks!
As I know this is not possible. You cannot use derived class from the entity instead of the entity. You must either map derived class as well or create new instance of the entity for persistence and copy all fields from your derived class instance to the entity instance.
I use standard ObjectContext and EntityObjects in my application. Let's say two of my tables are Projects & Services. Projects have Subproject (from Projects table with ParentID == ProjectID) and also Services. So I would have a hierarchy like Projects->Subprojects->Services. But I need to inherit Projects and Services from an abstract base class so I can use any of these entities as a new Task/Job entity in my application. Then, for example I can create a TreeList listing all Tasks (either a Project or Service). Is there anyway in EDMX designer I can create a new type (entity) which is the base calss for two or more concrete types?
It is possible with TPC inheritance but it will include a lot of complication to your design. For example:
you will have to move shared properties to the base class
you will probably have to maintain some mappings manually in EDMX (at least I had when I did the sample on screenshot)
you will have only single ObjectSet<Tasks> and you will have to use OfType to query only Projects or Services
you will have to use unique Id per Task = across both Project and Service tables (can be achieved by correctly configured identities in database)
It will look like:
Another option is using interface on your entity objects instead of parent class. You can define interface in your partial part of entity object and handle retrieving both Projects and Services by yourselves where your UI will expect only list of types implementing your interface.
http://blogs.microsoft.co.il/blogs/gilf/archive/2010/01/25/table-per-concrete-type-inheritance-in-entity-framework.aspx
Since it sounds like your data is coming from 2 separate tables, Projects and Services, no, I don't think you can achieve this in the designer (at least, not without hand-editing the generated edmx). If there were a common table to represent the base class, that could be done in the designer, but that doesn't sound like it fits your situation.
What you may be able to do is use an interface instead of an abstract base class, and use partial classes in your entity model to implement the interface for each of your entities. You can't directly inherit from your abstract base class in your entity model, because all of your entities already derive from EntityObject. If you have a lot of shared implementation that resides in your base class, it might be worthwhile to switch to POCO, where you can define your own inheritance hierarchy.
Our organization is looking to standardize on Entity Framework once v4 comes out. As a result, I am looking at what it would take to migrate our application that uses NHibernate for persistence to EF4 using POCO support. In a couple of places we use single table inheritance (also known as Table Per Hierarchy). I have been unable to get it to work using the following.
Payment (base class [should be abstract but having trouble there as well])
CreditCardPayment (concrete implementation)
ACHPayment (concrete implementation)
CheckPayment (concrete implementation)
Right now, I am mapping them with only the base class properties. All of these classes are in the same namespace. They have a discrimimator that is called PaymentTypeId in the database, so the Payment mapping has a condition of "When PaymentTypeId = 0". Each of the subclasses have the same condition with different values (i.e. CreditCardPayment = 1, etc.).
When I try to load each a list of all payments using DataContext.Payments.ToList() (DataContext inherits from ObjectContext) I am getting the following exception:
"Object mapping could not be found for Type with identity 'DataLayer.DataModel.CreditCardPayment'."
I can't figure out what this means, as the POCO CreditCardPayment class lives in the same namespace as the POCO Payment class does (in fact in the same file).
What am I missing?
This is complaining not about database mapping, but model to CLR mapping.
The EF can't for some reason find your CreditCardPayment class.
Now one possible reason is that you haven't loaded the metadata for it yet.
For example if you have this:
Assembly 1:
- Payment
Assembly 2 references Assembly 1:
- CreditCardPayment extends Payment
Then when you query the EF doesn't know where CreditCardPayment lives.
The way to get around this is with LoadAssembly i.e:
using (DataContext ctx = new DataContext())
{
ctx.MetadataWorkspace.LoadFromAssembly(typeof(CreditCardPayment).Assembly);
// now do your query.
}
You need to tell to LoadFromAssembly every assembly that isn't directly reference by your DataContext class.
Note: typeof(Payment).Assembly is directly referenced because of the IQueryable<Payment> Payments property.
Hope this helps
Alex
Microsoft.
What I didn't represent before (I didn't think it relevant, but it was). Was that CreditCardPayment inherited from an intermediary class named "CreditPayment" and ACHPayment inherited from CashPayment. CreditCardPayment and CashPayment live in the same namespace and file, but were not represented in the EF mapping. Once I added those within the mapping file, everything worked ok.
So, even thought EF does not ever map to one of those types directly, it seems to need to know about them, because it changes the basetype of the CreditCardPayment classes et al. Thank you for your help on this.
For part of the project I'm currently working on, I have a set of four tables for syndicatable actions. One table is the abstract base for the other three, and each table is represented in my EF model like so:
EF Model -- Actions http://chris.charabaruk.com/system/files/images/EF+Model+Actions.png
There are two problems that I'm currently facing with this, however. The first problem is that Actor (a reference to a User) and Subject (a reference to an entity of the class associated with each type of action) are null in my subclasses, despite the associated database columns holding valid keys to rows in their associated tables. While I can get the keys via ActorReference and SubjectReference this of course requires setting up a new EF context and querying it for the referenced objects (as FooReference.Value is also null).
The second problem is that the reciprocal end of the relationship between the concrete action classes and their related entity classes always turn up nothing. For example, Task.RelatedActions, which should give me all TaskAction objects where Subject refers to the particular task object on which RelatedActions is called, is entirely devoid of objects. Again, valid rows exist in the database, Entity Framework just isn't putting them in objects and handing them to me.
Anyone know what it is I'm doing wrong, and what I should do to make it work?
Update: Seems that none of the relationship properties are working in my entity model any more, at all. WTF...
I think the issue you are experiencing here is that by default the EF does not automatically load related entities. If you load an entity, the collection or reference to related entities will be empty unless you do one of the following things:
1) Use eager loading in order to retrieve your main entity and your related entity in a single query. To do this, modify your query by adding a call to the Include method. In your sample above, you might use the following query:
from a in context.Actions.Include("Actor") select a
This would retrieve each of the actions with the related Actor method.
2) Use explicit lazy loading to retrieve the related entity when you need it:
action1.ActorReference.Load()
In the version of the EF which will ship with .Net 4.0, you will also have the following additional option:
3) Turn on implicit lazy loading so that related entities will automatically be retrieved when you reference the navigation property.
Danny